Service Locator Pattern

For this week’s blog article, I will be looking at the Service Locator Pattern. The article explains how the Service Locator Pattern is a relatively old pattern that was originally used to improve the modularity of an application by removing the dependency between the client and the implementation of an interface. There are many principles that enable you to implement maintainable applications: the Open/Closed Principle, the Liskov Substitution Principle, the Interface Segregation Principle, and the Dependency Inversion Principle. Although these principles are all helpful, they all share the same issue. You need to provide an implementation of the interface, and if that’s done by the same class that uses the interface, you have a dependency between the client and the implementation.

The Service Locator Pattern avoids this dependency altogether. The service locator pattern acts as a central singleton registry that provides implementations of different interfaces. The component that uses the interface no longer needs to know the class that implements the interface, and instead of instantiating the class, it gets an implementation from the service locator. You can implement the service locator as a static service locator that uses a field for each service to store an object reference. Or you can create a dynamic service locator that keeps a java.util.Map with all service references.

Although the Service Locator Pattern can be helpful there are concerns against it and it is also largely outdated by the Dependency Injection pattern. The three most common concerns against the Service Locator Pattern are that all components need to have a reference to the service locator, which is a singleton, the service locator makes the application hard to test, and a service locator makes it easier to introduce changes in interface implementations.

The service locator pattern is just one of the many different patterns that you can use to decouple a client from the implementation of an interface. The pattern uses a singleton registry that provides an instance of a service interface. This helps to move the dependency to the interface implementations from the client of the interface to the service locator class. Although the pattern has some downfalls and is slightly outdated, it can still be used in certain situations.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s