My favorites | Sign in
Project Home Downloads Wiki Issues Source
Project Information
Members

This simple implementation of the service locator pattern has been used extensively in a number of large-scale commercial projects for over three years now. The only public domain project it is used in is the Turn Engine project.

What does this API give you?

  1. Tiny - only a handful of classes.
  2. Simple - access dependencies at any place in your code, no need to pass them around in constructors, setters or even as fields.

Service Locator Pattern - Why Use It?

For an overview of the general Service Locator pattern, refer Martin Fowler's article on inversion of control provides a good summary.

The key issue with this approach, which everyone is very quick to point out, is that you do not know up front what all the dependencies for an application are. This is indeed entirely accurate and without some documentation it is a case of trial and error. However in my experience using this approach for a number years now, this issue rarely arises in reality and the advantages far outweigh this minor irritation.

The main advantage of this approach is that it makes it easy to keep objects clean as you only need to reference those dependencies of specific interest. As a project grows, the clarity of code degrades, and an increasing amount of effort is required to keep it well organised and maintainable. This pattern removes one of the main causes of code degradation; how to make objects available where they are needed without having to pass them numerous other barely related classes.

It effectively enforces interface-driven design which provides true decoupling, a very important aspect of any application. With virtually every aspect of the code accessed through an interface, it demonstrates a flexibility otherwise unseen.

The decoupling it provides makes writing tests about as simple as it possible to make it. Because all dependencies are referenced by interface only, it is a trivial task to mock out those dependencies relevant to each test.

This pattern all but removes the need for singletons as its most frequent usage is that of a singleton repository.

Powered by Google Project Hosting