The Dreaded Service Locator Pattern

Torbjørn Marø recently blogged about Dependency Injection, due to Mark Seeman visiting the Norwegian .Net User Group in Bergen. This triggered my thinking about the dreaded Service Locator.

I have worked with several teams that favored a home-made ServiceLocator class, a static component referencing a set of services, typically chunks of functionality that are singletons that interact with something external like database, filesystem, or web-service.

My beef with the Service Locator is that you can put it in, and use it from anywhere: It can be used to grab services in a controller/action component, inside a service, in a domain object, inside a for-loop, anywhere. This sounds pretty powerful, but ends up bringing in a lot of maintenance problems.

Now, in spite of my troublesome experiences with it, I keep finding myself being pretty lousy at explaining the disadvantages of a ServiceLocator to my peers.

I therefore hunted through Seeman's blog for some better explanations, and here's what I found:

• Service Locator is an Anti-Pattern
• Pattern Recognition: Abstract Factory or Service Locator?
• Refactoring from Service Locator to Abstract Factory

He totally nails it in the first post:

Service Locator is a well-known pattern, and since it was described by Martin Fowler, it must be good, right?
No, it’s actually an anti-pattern and should be avoided.
Let’s examine why this is so. In short, the problem with Service Locator is that it hides a class’ dependencies, causing run-time errors instead of compile-time errors, as well as making the code more difficult to maintain because it becomes unclear when you would be introducing a breaking change.

Also have a look at the comments for some more discussion and affirmation.

Seeman has also written a book on the subject of DI, and Service Locator is discussed within. I haven't read it, but it sounds pretty good, especially if you work with .Net.

In case you got a little lost in his C# examples, here's my own take on it:

Let's say you want to test a CustomerRepository (an already initialized field in this test class):

@Test customerRepositoryHasCustomers {

  assertTrue(customerRepository.hasCustomers());

}

Bang! This explodes in a null-pointer because you haven't injected the proper services that are used inside the hasCustomers method (via ServiceLocator). So you try again:

@Test customerRepositoryHasCustomers {

  ServiceLocator.setRemoteCustomerService(new MockCustomerService());

  assertTrue(customerRepository.hasCustomers());

}

Bang again! This is because there is another service which is used inside the hasCustomers method a little later. 

As you can see, once you know what you need, the ServiceLocator is pretty straight forward to use.  And you don't notice this need during runtime, because the ServiceLocator is fully populated during startup.  

(This explains why the Service Locator being a perfectly fine pattern for those who don't enjoy writing tests.)

Then there's the maintenance issue: If you change the hasCustomers method to make use of even more services, you won't discover that the tests are broken until you run them again. Also the other way around: If you remove use of services in the method, you aren't reminded to remove this superflous setup from your tests.

In total, Service Locator removes a whole lot of compile-time verification that would be nice to have. Again, this doesn't matter much for those who don't write tests.

But, it does matter for the over all drive towards good code and architecture. Quoting Mark Seeman again (from the end of the third post):

Refactoring from Service Locator to Abstract Factories make it more painful to violate the SRP.

Using Service Locators breaks the window that usually stops you from giving a class too much responsibility. Usually, when you see the number of constructor, or method arguments are towering past a handful, you start thinking "refactor?". But with the Service Locator in use, you don't get this reaction.