This article is rated Stub-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Low This article has been rated as Low-importance on the project's importance scale.

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. 109.64.122.102 (talk) 09:57, 18 January 2014 (UTC)[reply]

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.

From reading this, I'd say that both techniques obscure dependencies by introducing a level of indirection. None is better in this regard. 109.64.122.102 (talk) 10:19, 18 January 2014 (UTC)[reply]

--- 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. 2.234.41.128 (talk) 18:53, 26 August 2014 (UTC)[reply]

The main criticism of service location is that it is an anti-pattern

Tautology? — Preceding unsigned comment added by Bartpio (talk • contribs) 04:34, 21 June 2018 (UTC)[reply]

The disadvantages section is dismissing both listed disadvantages. Should these dismissals not be removed? If they should remain, I think the dismissals should instead be reworded as advantages and listed in the advantages section so as not to hand-wave away the listed disadvantages. EvaUnit02 (talk) 19:20, 15 October 2024 (UTC)[reply]

ransition transition = TransitionInflater.from(getContext()).inflateTransition(R.transition.image_shared_element_transition); transition.setDuration(375); 2806:3E8:101:1008:4174:B31C:51FE:A962 (talk) 04:52, 22 November 2024 (UTC)[reply]