Service Locator

I mentioned in my last blog entry that I want to discuss the idea of the Service Locator pattern as an alternative to Dependency Injection. However, I first wanted to discuss each pattern individually. So here's what I have to say about Service Locator.

At the root of the Service Locator pattern, the idea is that a single object has access to all the services that your system/component needs. It will handle acquiring, creating, or connecting to those services. In a simpler environment, it may simply be holding references to objects (as compared to performing complex lookups for services in an enterprise environment). With that in mind, how could the Service Locator pattern help us?

Benefit #1
First, let's look at a very simple example. Consider the following:

class SimpleExample {
  private MessageGenerator generator;

  public  simpleExample() {
    this.generator = new MessageGeneratorImpl();
  }

  public void initiateSession() {
    Message message = this.generator.createInvite();
    this.generator.sendMessage(message);
  }
}

What benefit would we see from changing it to user a Service Locator like this?

class ServiceLocator {
  private static Map services = new HashMap();

  public static void addService(String name, Object service) {
    map.put(name, service);
  }

  public static Object getService(String name) {
    return services.get(name);
  }
}


class SimpleExample {
  public  simpleExample() { }

  public void initiateSession() {
    MessageGenerator generator = ServiceLocator.getService("MessageGenerator");
    Message message = generator.createInvite();
    generator.sendMessage(message);
  }
}

The primary benefit here is that the SimpleExample class is no longer coupled to the implementation of MessageGenerator. The SimpleExample class relies on the ServiceLocator to provide the correct implementation. So, removing a direct dependency between a class and its needed service is one thing the ServiceLocator can accomplish.

Benefit #2
Now, let's think bigger. Consider having 10 classes, each needing to use several of 8 different services in your application. Imagine how messy (and tightly coupled) things would be with each class having a direct dependency on each service it needed.

What would happen if instead we used ServiceLocator to manage access to those 8 services. Well, none of the classes would require direct knowledge of any service. They could simply use a public method on the Service Locator to acquire a service when necessary. So, we've gone from 10 classes having 3,4,5, or more direct couplings to services; to simply interfacing through public methods on the Service Locator.

How much cleaner and readable would the code become? So, organization and readability can be improved in this scenario by implementing Service Locator.

Conclusion
There is a whole lot more to talk about when discussing the Service Locator pattern. However, I think the two benefits I've show here are enough to discuss this pattern being an alternative to Dependency Injection. So, I'm going to stop here for now. Maybe I'll put up a more detailed discussion of Service Locator in the future.

Some Service Locator links:
Martin Fowler
Core J2EE Pattern Catalog on java.sun.com
Another description on java.sun.com