1. Introduction
In this tutorial, we’re going to learn about the Service Locator design pattern in Java.
We’ll describe the concept, implement an example and highlight the pros and cons of its use.
2. Understanding the Pattern
The purpose of the Service Locator pattern is to return the service instances on demand. This is useful for decoupling service consumers from concrete classes.
An implementation will consist of the following components:
Client – the client object is a service consumer. It’s responsible for invoking the request from the service locator
Service Locator – is a communication entry point for returning the services from the cache
Cache – an object for storing service references to reuse them later
Initializer – creates and registers references to services in the cache
Service – the Service component represents the original services or their implementation
The original service object is looked up by the locator and returned on demand.
3. Implementation
Now, let’s get practical and have a look at the concepts through an example.
First, we’ll create a MessagingService interface for sending messages in different ways:
public interface MessagingService {
String getMessageBody();
String getServiceName();
}
Next, we’ll define two implementations of the interface above, that send messages through email and SMS:
public class EmailService implements MessagingService {
public String getMessageBody() {
return "email message";
}
public String getServiceName() {
return "EmailService";
}
}
The SMSService class definition is similar to the EmailService class.
After defining the two services, we have to define the logic to initialize them:
public class InitialContext {
public Object lookup(String serviceName) {
if (serviceName.equalsIgnoreCase("EmailService")) {
return new EmailService();
} else if (serviceName.equalsIgnoreCase("SMSService")) {
return new SMSService();
}
return null;
}
}
The last component we need before putting the service locator object together is the cache.
In our example, this is a simple class with a List property:
public class Cache {
private List<MessagingService> services = new ArrayList<>();
public MessagingService getService(String serviceName) {
// retrieve from the list
}
public void addService(MessagingService newService) {
// add to the list
}
}
Finally, we can implement our service locator class:
public class ServiceLocator {
private static Cache cache = new Cache();
public static MessagingService getService(String serviceName) {
MessagingService service = cache.getService(serviceName);
if (service != null) {
return service;
}
InitialContext context = new InitialContext();
MessagingService service1 = (MessagingService) context
.lookup(serviceName);
cache.addService(service1);
return service1;
}
}
The logic here is fairly simple.
The class holds an instance of the Cache. Then, in the getService() method, it will first check the cache for an instance of the service.
Then, if that’s null, it will call the initializing logic and add the new object to the cache.
4. Testing
Let’s see how we can obtain instances now:
MessagingService service
= ServiceLocator.getService("EmailService");
String email = service.getMessageBody();
MessagingService smsService
= ServiceLocator.getService("SMSService");
String sms = smsService.getMessageBody();
MessagingService emailService
= ServiceLocator.getService("EmailService");
String newEmail = emailService.getMessageBody();
The first time we get the EmailService from the ServiceLocator a new instance is created and returned. Then, after calling it the next time the EmailService will be returned from the cache.
5. Service Locator vs Dependency Injection
At first glance, the Service Locator pattern may look similar to another well-known pattern – namely, Dependency Injection.
First, it’s important to note that both Dependency Injection and the Service Locator pattern are implementations of the Inversion of Control concept.
Before going further, learn more about Dependency Injection in this write-up.
The key difference here is that the client object still creates its dependencies. It just uses the locator for that, meaning it needs a reference to the locator object.
By comparison, when using the dependency injection, the class is given the dependencies. The injector is called only once at startup to inject dependencies into the class.
Finally, let’s consider a few reasons to avoid using the Service Locator pattern.
One argument against it is that it makes unit testing difficult. With dependency injection, we can pass mock objects of the dependent class to the tested instance. On the other hand, this is a bottleneck with the Service Locator pattern.
Another issue is that it’s trickier to use APIs based on this pattern. The reason for this is that the dependencies are hidden inside the class and they’re only verified at runtime.
Despite all of this, the Service Locator pattern is easy to code and understand, and can be a great choice for small applications.
6. Conclusion
This guide shows how and why to use the Service Locator design pattern. It discusses the key differences between the Service Locator design pattern and Dependency Injection concept.
In general, it’s up to the developer to choose how to design the classes in the application.
Service Locator pattern is a straightforward pattern to decouple the code. However, in case of using the classes in multiple applications, dependency injection is a right choice.
As usual, the complete code is available in the Github project.