The service locator pattern is a design pattern used in software development to encapsulate the processes involved in obtaining a service with a strong abstraction layer. This pattern uses a central registry known as the "service locator", which on request returns the information necessary to perform a certain task. Proponents of the pattern say the approach simplifies component-based applications where all dependencies are cleanly listed at the beginning of the whole applicationdesign, consequently making traditional dependency injection a more complex way of connecting objects. Critics of the pattern argue that it is an anti-pattern which obscures dependencies and makes software harder to test.
Advantages
The "service locator" can act as a simple run-timelinker. This allows code to be added at run-time without re-compiling the application, and in some cases without having to even restart it.
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.
Large sections of a library or application can be completely separated. The only link between them becomes the registry.
An application may use multiple structured service locators purposed for particular functionality/testing. Service locator does not mandate one single static class per process
The solution may be simpler with service locator in applications with well-structured component/service design. In these cases the disadvantages may actually be considered as an advantage
Disadvantages
The registry hides the class' dependencies, causing run-time errors instead of compile-time errors when dependencies are missing. But each library is compiled, just the discovery of the concrete Class might not be found and make error, it's more a deployment issue than a Service Locator issue.
The registry makes code harder to test, since all testsneed to interact with the same global service locator class to set the fake dependencies of a class under test. However, this is easily overcome by injecting application classes with a single service locator interface. Simulator can be implemented to simulate each interface provided by the service locator, so it's easy to swap the real implementation with a simulator.