Follow-up: Service Locator Pattern

I decided to post a follow up to my service locator design pattern post based on all the feedback I received. I certainly agree with the notion that, for most, this pattern is considered a nono anti-pattern that should never been touched or seen in the corporate world. However, this pattern is seen ALL THE TIME in the corporate sector. Whether the community wants to admit it or not.

I received at least a dozen messages linking Mark Seemann’s excellent post on the Service Locator being an anti pattern. For the record, I wholeheartedly agree with Mark that his argument holds truth when it comes to developing API’s. Withholding dependencies in your API from a user until run-time can be a severe oversight in any circumstance.

However, there are rare circumstances when this pattern can and does make sense. In my case, this was third party integration of a standard canonical message. I was able to build one endpoint for all third parties (over 100) to use and also have their own ‘unique’ logic for processing data that was unique to their system, while keeping most of the common processing in the base message flow.

Is the Service Locator a commonly occurring solution to a problem that generates decidedly negative consequences? Absolutely. Every pattern (or anti-pattern) can and does have distinct advantages and disadvantages that should be recognized. Any pattern poorly implemented can cause drastic issues in production, and when is the last time you saw a Facade or Abstract Factory implemented perfectly?

My point is, don’t be afraid to go against the community grain if the design makes sense for your situation. Talk and discuss it with your teammates and if it makes sense, do it.