Service locator pattern

<h2 id="advantages">Advantages</h2>
<ul><li>The "service locator" can act as a simple <a href="/facts/Run_time_(program_lifecycle_phase)/lCxKsrzB">run-time</a> <a href="/facts/Linker_(computing)/pn1hztYe">linker</a>. This allows code to be added at run-time without re-compiling the application, and in some cases without having to even restart it.</li>
<li>Applications can optimize themselves at run-time by selectively adding and removing items from the service locator. For example, an application can detect that it has a better library for reading JPG images available than the default one, and alter the registry accordingly.</li>
<li>Large sections of a library or application can be completely <a href="/facts/Separation_of_concerns/Tx8jawNT">separated</a>. The only link between them becomes the registry.</li>
<li>An application may use multiple structured service locators purposed for particular functionality/testing. Service locator does not mandate one single static class per process.</li>
<li>The solution may be simpler with service locator (vs. dependency injection) in applications with well-structured component/service design. In these cases, the disadvantages may actually be considered as an advantage (e.g., no need to supply various dependencies to every class and maintain dependency configurations).</li>
<li>Service location process can be made sensitive to a calling scope/context which can represent a specific business case. Instead of relying on a fixed DI which typically supplies an object with its dependencies via a constructor parameter passing, the service location call can be made in a business context as needed. For example, you may wish to invoke a "IShippingStrategy" instance obtained via a service location call, supplying a "ShippingContext" as a parameter to service locator stating what is being shipped from where and where to, so service locator can match the best case (e.g. using a pattern match score). This significantly simplifies complex business application architecture (e.g. medical scoring systems, routing) where circuitous decision making can be done via scoring of the best matching strategy located dynamically at a runtime</li></ul>
<h2 id="disadvantages">Disadvantages</h2>
<ul><li>The registry hides the class' dependencies, causing <a href="/facts/Run-time_error/lCxKsrzB">run-time errors</a> instead of compile-time errors when dependencies are missing (unlike when using <a href="/facts/Dependency_injection/Vp9LdwhU">constructor injection</a>).</li>
<li>The registry makes code harder to <a href="/facts/Software_testing/VoXzG9Tb">test</a>, since all tests need to interact with the same global service locator class to set the fake dependencies of a class under test.</li></ul>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Dependency_injection/Vp9LdwhU">Dependency injection</a></li>
<li><a href="/facts/Dependency_inversion_principle/wkJ1aFvy">Dependency inversion principle</a></li>
<li><a href="/facts/Java_Naming_and_Directory_Interface/StLyNcyy">Java Naming and Directory Interface</a></li></ul>

<h2 id="external-links">External links</h2>
<ul><li><a href="http://www.oracle.com/technetwork/java/servicelocator-137181.html">Sample code</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>Fowler, Martin. "Inversion of Control Containers and the Dependency Injection pattern". <a href="http://martinfowler.com/articles/injection.html#UsingAServiceLocator" target="_blank">http://martinfowler.com/articles/injection.html#UsingAServiceLocator</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>Seemann, Mark. "Service Locator is an Anti-Pattern". blog.ploeh.dk. Retrieved 2017-06-01. <a href="http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/" target="_blank">http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
</ol>

Service locator pattern open-in-new

Service locator pattern