Talk:Service locator pattern
|WikiProject Computing||(Rated Stub-class, Low-importance)|
The section on disadvantages currently says that:
The registry makes the code more difficult to maintain (opposed to using Dependency injection), because it becomes unclear when you would be introducing a breaking change
"more difficult" here is totally subjective. You can't count the difficulty here, or at least you have to define what is meant by "difficult" and then show how the amount is different when using two strategies. My experience with both technologies is that neither has any benefits when it comes to noticing breaking changes. (PoV again). Of course, DI needs to be mentioned in the context of Service Locator, because it is the perfect opposite of it, but not as a superior, rather as an equivalent mechanism. There are projects which try to promote the idea of DI superiority, but I'm afraid it has to do with marketology, or maybe a kind of blind conviction. 220.127.116.11 (talk) 09:57, 18 January 2014 (UTC)
- Actually, here, to back up my point, the quote from Dependency Injection article:
The dependency injection container makes the code more difficult to maintain, because it becomes unclear when you would be introducing a breaking change.
--- I agree that there is no superiority, also the two technologies can be combined defining a priority, usually first injection and then, if no injection present, default to service locator. This is also the common way of refactoring legacy code. I want to add on the differences between the two: with DI, when one configures it, he needs to know the implementation name, while with service locator configuration might not be needed and the client be unaware of this aspect. At the same time one implementation, configured for a service locator, might not be actually used since in some environments could not even be possible to load it and an other implementation is served, this is not normally possible with DI. 18.104.22.168 (talk) 18:53, 26 August 2014 (UTC)