The Object Oriented Programming (OOP) methodology has origins dating back to the 1950s, but revolutionized the software industry when it became the dominant programming methodology in the 1990s. It has continued to dominate to this day where it remains the foundation of all of modern major software development languages including C++, Java, Ruby, PHP5, and many more. OOP is universally accepted as the best-practice methodology for software development across the majority of computing platforms and provides developers with a unique approach to software design that elegantly mimics real world concepts through the use of objects.
Service Locator is a serivces oriented design pattern which misappropriates concepts of the Services Oriented Architecture (SOA) paradigm. SOA arose from a need to integrate discreet systems that were built independently using incompatible technologies (eg: EJB and CORBA) across networks. It revolutionized software integration and has facilitated countless integrations of otherwise completely incompatible systems and platforms. SOA concepts work extremely well when applied to the software integration space, however a services oriented architecture has no place in application development. The Service Locator pattern capitalises on the success of SOA by tapping into the hype around services oriented architecture, but the problem is it applies the concepts in the wrong context, in the same way a screwdriver is an excellent tool for fastening a screw, but not for a nail. A software application by definition is a tailored package of software components specifically designed to work together in providing a set of functionality. There are no incompatible technologies as the software developer carefully chooses the components that are used. A services oriented design approach, and therefore a Service Locator pattern is not required, not useful, and is generally counter-productive.
By its very name, everything in OOP is oriented around the concept of an”Object”. The Service Locator pattern breaks this pattern by orienting everything around the concept of a “Service”. “Model” objects within the Service Locator pattern (ie: objects representing domain entities) are generally reduced to dumb containers for data offering little advantage over primitive structures such as arrays. Service Locator pundits stress to never allow domain objects the ability to know about the service manager, causing these objects to become detached, powerless, and oblivious of the wider system in which they reside. Even the relationship between domain objects and the software developer becomes fragmented as the Service Locator pattern relies on Services to do just about everything.
This is in direct conflict with the most fundamental of OOP principles which require that objects interact with each other and specifically are able to “do” useful things (ie: perform actions) via methods above and beyond simply getting and setting their own attributes. A classic example is the “Car” object which has the methods “Drive” and “Stop”. A car is a complex machine with many many internal parts (pistons, spark plugs, camshaft, etc), however car drivers are not generally concerned with all of this as the car does a great job of abstracting away all of its complex internal components into a simple method “Drive” which is invoked by the driver depressing one pedal (or invoking one method). The Service Locator pattern breaks this so that a car no longer knows how to drive. In fact, even the spark plugs no longer know about the pistons. Instead, objects become little more than a catalogue of parts which rely on a service to instantiate and assemble them in the same way a puppeteer pulls the strings on a puppet. In OOP, objects were never intended to be merely puppets.
The Service Locator pattern wraps and proxies the highly structured and namespaced class hierarchy system offered by OO languages with what’s essentially and unstructured, global key/value pair system that offers no advantage except to satisfy someones perverted desire to implement the Service Locator pattern. Global variables are generally avoided in software development due to several problems they introduce into a system, especially around security and scope. Services stored in the global registry are generally done so in a loosely-typed fashion which is not only at odds with OOP principles but compromises the strongly typed qualities of languages like C# and Java.
The Service Locator pattern violates the Interface Segregation Principle of the SOLID set of Object Oriented Design principles which states that “clients should not be forced to depend on methods they do not use”. It’s impossible for the Service Locator design pattern to satisfy this as the Service Manager can expose any number of method signatures globally to the entire application, and these can be changed at any time without detection at compile-time, thereby resulting in run-time errors.
The Service Locator software design pattern is an object UNoriented fad that will disappear into obsolescence as more and more people speak out against it and its related concepts. Personally, I think that can’t come soon enough.