Talk:Dependency injection

From Wikipedia, the free encyclopedia

Contents

[edit] Links

[edit] 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)

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)

[edit] sans-serif font confused me

loC (L) and IoC (i) can you tell the difference?

I thought it was reusing the acronym for "Lines of Code".

IoC loC IoC loC IoC loC IoC loC IoC loC IoC loC IoC —The preceding unsigned comment was added by 71.103.106.212 (talk) 18:47, 25 January 2007 (UTC).

IOC IOC when all capital, it is clearer that this must be an i, since it (usually) does not make sense for the first letter of an all-capital acronym to be lowercase.

[edit] I don't think "Dependency injection" is a misnomer

From the article:

The term "Dependency injection" is a misnomer, since it is not a dependency that is injected, rather it is a provider of some capability or resource that is injected.

I don't think that is true. The point if DI is that you don't pass in a provider, but you pass in the actual object itself. Does anyone object to this line being removed?

I don't think that is, too. If you need to pass a "provider", you depend on that, otherwise your class can't work obviously. So a dependency is created! --89.247.114.46 10:26, 8 July 2007 (UTC)

[edit] Dependency Injection = Inversion of Control ?

IMHO Dependency Injection is the concept of providing an object with the dependencies it needs instead of having the object collecting/creating the dependencies it needs.

Lets assume there is a service (A) that needs anorther service (B) to be fully operational.
Now there are two options:

  1. A itself obtains B somehow from somewhere
  2. A receives B somehow from somewhere

What are differences?
Case 1: A needs to know how and from where to obtain B and which B (think of polymorphism)
Case 2: A does not need to know anything. Just provide the capability to receive B.

That is IMHO the basics of Dependency Injection.

It is somehow obvious that case 2 can only be achieved if some third component provides B for A.
Usually this part is refered to as Inversion of Control, since A is no longer responsible for setting up its dependencies.

But generally I wouldn't say that Inversion of Control is the same as Dependency Injection.
Inversion of Control appears to be necessary to have Dependency Injection.

But there are also situations where Inversion of Control is used for other things, like receiving events from a component by adding a listener to that component.
The listener clearly is not a dependency (the component would very well operate normally without any listener) but since the listener does not control when it is invoked, this clearly is Inversion of Control.

195.64.29.62 13:55, 29 May 2007 (UTC)

[edit] Introduction too short

"the lead section should briefly summarize the most important points covered in an article in such a way that it can stand on its own as a concise version of the article" (WP:LEAD) --the Wild Falcon (talk | log) 13:13, 3 October 2007 (UTC)

[edit] Dynamic language best for illustrating DI?

Are dynamic languages the best for expressing the point and benefits of DI? It seems to me that static types, with all their language constraints, demonstrate the value of DI better. I'm not trying to start a static/dynamic war. I think having both examples would be fine. For a total newbie, it seems that DI becomes more immediately obvious with static languages like Java or C# or something like that. In fact, though it makes me cringe, it might actually be beneficial to have a VB.NET demonstration which might help make an even broader scope of developers aware of DI.

Thoughts?

(update: I'd be happy to do the examples, but I just wanted to make sure I wasn't going to get my changes snarfed immediately if anyone disagreed) Chadmyers (talk) 18:12, 18 November 2007 (UTC)


I totally agree, and thanks for the offer!--Penguin020 14:59, 7 April 2008 (UTC) —Preceding unsigned comment added by Penguin020 (talk • contribs)

[edit] Dependency Injection vs Composition

I found this paragraph in the introduction:

Dependency injection is where the implementation of one class is actually performed partially by another - the injected class (see the example below). Typically there are multiple variants (sub-classes) of the injected class. The main class abstracts out the common code required by all implementations and delegates to the injected class where specific behaviour is required.

How then does DI differ from composition? I believe this paragraph does not correctly describe Dependency Injection. DI is about injecting dependencies and comes after the decision to use composition. Therefor DI cannot have the design characteristics of composition. DI is the act of injecting objects. —Preceding unsigned comment added by 213.189.190.8 (talk) 17:06, 13 December 2007 (UTC)

[edit] Delete this article

This article needs to be deleted along with Inversion of Control. Both are red herrings. Dependency injection = usage of callbacks and IoC = abstraction layer. For some unknown reason Martin Fowler and others in the software obfuscation industry have decided to rename concepts which already have perfectly good names. Wikipedia doesn't have to stand for this nonsense. Just because Martin Fowler and a few others sucking at the teat of Enterprise prefer Java to C doesn't mean Wikipedia has to follow his lead. Mistercupcake (talk) 07:31, 29 December 2007 (UTC)

[edit] Questions

In the introduction: Dependency injection (DI) refers to the process of supplying an external dependency to a software component [...]

is dependency here what's meant with dependency in the Coupling (computer science) article?

Also, with the article's introduction, I understood dependency injection being all about an object's reference attributes to other objects. In the then following example, it seems to be about implementation of methods. What about these fragmented code samples

      def __init__():
          self.foo = EnterpriseFoo()

and

      def __init__(self, foo):
          self.foo = foo

? Are they supposed to be inside a class? is __init__ a constructor? What is self.foo? Thanks, --Abdull (talk) 12:18, 3 February 2008 (UTC)

[edit] Sample Code

I can read C# fine. I can read Java fine. Same goes with C++, C, VB, and Pascal. What I can't read is this bullshit:

   class EnterpriseFoo(object):
      interface.implements(IFoo)
      def do_bar():
          bar = EnterpriseFactoryObserverFactoryCreator("bar")
          bar.creatify()
          bar.preparify()
          bar.configurise()
          bar.make_award_winning()
          bar.opportunities.leverage()
      def do_baz():
          baz = EnterpriseFactoryObserverFactoryCreator("baz")
          baz.creatify()
          baz.preparify()
          baz.configurise()
          baz.make_award_winning()
          baz.opportunities.leverage()  —Preceding unsigned comment added by 198.87.24.254 (talk) 15:46, 19 March 2008 (UTC)

I agree: I have coded in a dozen languages, and this syntax is out of my scope. If a concept can be expressed in a common language, use a common language! Use a language that at least is taught to all Computer Science classes for the last 10 years (C, Java, Pascal). --Penguin020 14:56, 7 April 2008 (UTC)

[edit] 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)

[edit] Dependency Injection is fictitious. Don't believe the HYPE!

The Martin Fowler article on this subject is highly dubious. He is trying to draw similarities between different frameworks, but the fact is that the frameworks really are essentially different. In fact the only thing you can say is that the frameworks use observer patterns and perhaps some data-directed configuration. Fowler and a few of his flunkies seem intent on slathering this admittedly powerful combination with vast amounts of pomo-esque hype... This is why software developers have a bad reputation amongst some clear-thinking individuals! DON'T BELIEVE THE HYPE!!! Remember: patterns are only good if they help you communicate with other developers. This is why they exist. Don't describe your work using patterns that are too fuzzy for their own good. Mistercupcake (talk) 07:23, 19 April 2008 (UTC)

[edit] haha

The EnterpriseFoo example is awesome. Best piece of humor that I ever read on Wikipedia. Yeah, I know Wikipedia is not for humor in articles or even for posting thank-you messages like this in discussion sections like this, but someone has to say it :P - 84.112.133.91 (talk) 20:49, 1 May 2008 (UTC)

[edit] PseudoCode Differs?

It appears that the pseudocode immediately following 'However, this defeats the entire point of using an interface instead of a concrete implementation.' differs in format from the rest of the pseudocode in the article. Could someone modify it to more accurately reflect the changes in the standard form of pseudocode? 38.98.105.130 (talk) 14:08, 9 June 2008 (UTC)

[edit] Merging with Dependency inversion principle

The Dependency inversion principle barely manage to define its concept, and if fails to differentiate itself from Inversion of Control and Dependency injection, mudding these already unclear pages. Since the goal of dependency injection is to follow the dependency inversion principle, I suggest to merge both and achieve a stronger article, instead of two weak ones. Diego (talk) 08:54, 10 June 2008 (UTC)

Thinking about it, Dependency injection and the Dependency inversion principle are different enough concepts to have different articles for them (the first is a technique, the second is an guideline to apply it). What is really needed is a rationale explaining how these concepts relate to each other and to Inversion of control. Diego (talk) 15:02, 12 June 2008 (UTC)