Common Service Locator - one interface to rule them all

If we shouldn't do it, we shouldn't be _able_ to do it. © Bujold

In my previous post on Common Service Locator I do not argue against the presence of the common interface at all. The initiative itself is great. Standards are the thing that have allowed the mass production of high-quality cars at an affordable price (as well as thousands of other things).

But I'm against creating one single Common Service Locator interface to rule them all and making it so flexible and powerful.

Powerful interface that holds too much flexibility could be abused. And it will be abused. That's the Murphy's law. Or the "users tend to pick the path of the least resistance" law.

To prevent some of the unpredictable side effects, this flexibility will have to be tested in all combinations (BTW, setting up IoC Container in the test fixture of some component or a service in not a good sign at all). This will add more complexity to the code by making it less maintainable.

I'm not against the common interface, but rather against the almighty one that encourages bad development patterns and practices.

PS: Common Service Locator breaks the SOC, by the way. Update: Alternative to CSL has been proposed.

Comments

[Jeremy Gray]

Can you elaborate on what you mean by "so flexible and powerful"? I ask because the people behind it seem to believe that it provides only the most basic and common of service location capabilities.

I'd be similarly interested to hear why you feel that it breaks SOC.

[Another alternative to the Sin]

[...] to make my argument against powerful Common Service Locator Interface more constructive [...]

[Rinat Abdullin]

Jeremy,

1. Using CSL interface is just like using IList instead of IEnumerable{T} everywhere.

2.
Concern of Service Locator: ability to locate the service, given it's type (i.e. getting ILog)

Concern of Service Dictionary: ability to get service instance, given it's type and name (i.e.: getting named exception handling policy or business workflow)

Concern of infrastructure code: ability to query the service provider for a list of service instances that it has

[Common IoC denominator for Aut]

[...] there is also clarification on my position towards CSL and roll-up of the proposed alternative [...]

[Jeremy Gray]

And now you're just inventing pattern names. Locator/dictionary/directory/whatever. Before generics or the passing of types such interfaces only had names to key on anyway, so attempting to distinguish the way you have in your comment is wishy-washy at best. Looking things up by both name and type rather than just its type is a separate concern? Getting a list of named instances is a separate concern? You must really enjoy splitting hairs. It's all Service Locator, something that existed long before generics and long before types that could be passed around the way we do in .net.

PS - you have yet to answer why you feel that the common Service Locator is too powerful and too flexible. Since your code samples are equally powerful, equally flexible, and in fact are more complicated, I expect your answer to be interesting. :)

[Rinat Abdullin]

Jeremy,

Sorry to disappoint you, but the answer will be rather boring))

1. Re powerful Service Locator interface: using IServiceLocator in the components everywhere is just like using non-generic IList instead of IEnumerable{T} everywhere.

2. Re splitting hairs: yes I'm. And I'm doing this based on the patterns that I've observed in the .NET code so far.

Additionally, if service locator has existed in pre.NET code, it does not mean that it has to enter the strongly typed realm with well-designed logics of code (the one that makes you fall into the pit of success) unchanged.