Talk:Dependency injection/Archives/2012/November

Criticism

DI has been generaly accepted as something great, but there are some criticism that are quite valid to this practice. I believe that a good article about the subject must take in consideration "the dark side" of DI. Refer to this blog post and this other blog post for more detais on this subject.Ramiro Pereira de Magalhães (talk) 17:24, 4 April 2008 (UTC)

Could you enumerate the criticisms you see presented in these articles? The first article seems more a discussion of DI as it relates to Architecture Description Languages, but I didn't see any clear criticisms set forth. The second article is actually a pro-DI article which addresses someone's assertion that DI increases coupling. While this could result if the responsibility of resolving dependencies were assigned to each component's consumer, this is not a typical use of dependency injection and therefore isn't really a legitimate criticism. The only real criticism I see with the use of DI is increased complexity, but this is true of many patterns.--Derekgreer (talk) 21:13, 4 January 2009 (UTC)

Sorry, I misquoted the first blog post. It is correct now. I'll work on enumerating those criticisms when I get time since many interesting parts are in the comments made by those blogs readers and in the links inside the blog post. Ramiro Pereira de Magalhães (talk) 14:46, 11 January 2009 (UTC)

Problems with the term "Dependency Injection" and "Inversion of Control"

"Dependency Injection" is a vague description the practice it refers to. That practice is to externalize connections between components either in a specific third component or by using a configuration file to direct a general configuration component to do it. Injecting the dependency is only a part of the process.

"Inversion of control" as described in that article and elsewhere is clearly a misnomer. If class X depends on class Y then inserting the interface I such that X depends on I and Y implements I, is no inversion. To qualify as inversion Y would have to depend on X, not I. Precision-nazi 09:24, 6 August 2006 (UTC)

You have to consider what is being inverted. The practice of inverting the dependency relationship between X and Y is a technique described by the Dependency Inversion Principle. With Dependency Injection, what is being inverted is the responsibility (i.e. the control) of instantiating dependencies.--Derekgreer (talk) 20:21, 4 January 2009 (UTC)

It seems that Setter, Constructor and Interface under the list of styles should be more precise about where they point. Setter currently points to the dog, whereas Constructor and Interface point to disambiguation pages; they should all point specifically to pages about the styles of dependency injection. --134.173.86.14 06:37, 24 January 2007 (UTC)

The obvious question about the term "dependency injection" is "what is being injected?" When I first heard the term I thought it meant that there were some kind of software objects called "dependencies" and that they were being injected into something. Now I suspect that it is OOP objects that are being injected and that the meaning is really "dependency-driven injection." I have no problem with the article being titled "dependency injection" but would like an explicit statement as to what is being injected. It also wouldn't hurt to give an example of a dependency. The article mentions loading a driver and probably this is an example - the method depends on a driver to work - but this should be made explicit. Gene.Naden (talk) 01:35, 14 December 2010 (UTC)

Needs more pictures

To be easier to understand especially for users who may have hit this page just exploring software-articles, it would be good to have a couple diagrams that conceptually represent what is going on. There are various diagrams which could help to illustrate including UML. Also a dependency diagram may not be able to show the differences in design and coupling, but might stand as useful to clarify the problem-statement. The wording in this article I think is clunky by nature of the fact that software patterns (muchless largescale software development, muchless computing, muchless personal computing) are a relatively new thing, therefore I think before folks are willing to slog through an article like this one to gain some comprehension of the subject, they might want a visual aid to get the gears turning. Koyae (talk) 03:50, 27 November 2012 (UTC)