6 ms·

Genuinely curious : i've been playing with dependency injection, and really never got to understand the true use of it. I mean, what's the point of being able

by bsaul 13y ago

Genuinely curious : i've been playing with dependency injection, and really never got to understand the true use of it. I mean, what's the point of being able to replace an implementation outside the source code itself ? You'd still have to extensively test the thing and recompile it... Is there more to it than just being able to replace a class by its mock up, for unit testing ?

volune 13y ago
IMO dependency injection encourages making very deep object graphs. constructor argument passing can be cumbersome, but jumping into new code it is much more clear, and it encourages you to write flatter code structures. i go without.
snikeris 13y ago
I think the point is that you don't want to be instantiating (and thus configuring) a dependency at the site where it is used. The code in class Foo should be limited to implementing Foo, not instantiating and configuring its dependency Bar.
- wtetzner 13y ago
  So why not just pass its dependency as a constructor argument?
  - snikeris 13y ago
    Passing a dependency as a constructor argument is dependency injection: http://en.wikipedia.org/wiki/Dependency_injection#Constructor_injection http://en.wikipedia.org/wiki/Dependency_injection#Constructo...
    - wtetzner 13y ago
      Right, my point was more "why do you need a framework to call constructors for you?".
  - UK-AL 13y ago
    That's what IoC containers do, or via setter. However a IoC container can automatically create, and send through the object based convention(IMessageQueue -> MappedTo -> MessageQueue) or configuration (IMessageQueue -> MappedTo -> APMQMessageQueue).
oh_sigh 13y ago
Not to sound snarky, but you should read any introduction to dependency injection. The benefits are generally covered very thoroughly, and what you said is not usually considered a benefit.
- kyberias 13y ago
  Wikipedia article on dependency injection, section titled "Advantages", _first_ bullet: "The result is more independent clients that are easier to unit test in isolation using stubs or mock objects that simulate other objects not under test." Would you like to try again?
  - oh_sigh 13y ago
    The OP said "I mean, what's the point of being able to replace an implementation outside the source code itself." Where, in what you posted, does it reference being able to replace implementations outside of the source code itself? Would you like to try again?
deleted 13y ago
[deleted]
rymndhng 13y ago
It depends. One thing that I thought is an interesting feature of Spring, is that it allows the framework to inject code between your dependencies like decorators. This allows them to do aspect-oriented-programming transparently. And I think there's some interesting ideas here. For example, you can mark the interface of a class as @Transactional, and all your implementations will get the behavior.
- UK-AL 13y ago
  I think that's the interception way of AOP? Unity IoC in c# also does this. The IoC container will return transparent proxy(Not the original object), which then calls the underlying method(after doing the AOP behaviour).
  - Glide 13y ago
    Be careful of using these though. I had an obscure bug using dynamic proxy (castle dynamic proxy2) a while ago in a WPF application. I was proxying to an interface so it created a proxy object in between that in the actual class so it was eating my C# event. Changing the proxying from an interface to a subclass fixed it. Boy that was a fun one to figure out.
twistedpair 13y ago
When you've got a complex graph of objects and dependencies between them, DI can easily take care of instantiating an A and feeding it to a B that requires an A and so on and so on. In our projects we'll have a DebuggerFooImpl, a MockFooImpl, and a ProdFooImpl. Spring's AppConfig classes then can create the proper object at startup based on environment profiles and no consumers have to do any more than ask for the Foo object to be injected into them, isolating them from any environment awareness/coupling. There are other benefits from DI as well, but the above at the low hanging fruit, isolating the complexity of object creation from the object's consuming classes.
Terr_ 13y ago
It tries to disentangle two different problems: 1. Does my class work appropriately? Does it encapsulate/hide/abstract the right behavior? Does it function correctly with other classes that implement certain inferfaces? 2. Is my network of classes correctly defined so that I can use them all together in a particular way? http://programmers.stackexchange.com/questions/92393/what-does-the-spring-framework-do-should-i-use-it-why-or-why-not/92672#92672 http://programmers.stackexchange.com/questions/92393/what-do...
ddeck 13y ago
There are definitely more advantages than just the unit testing side. The Google IO talk on Guice does a pretty good job of explaining the benefits: https://www.youtube.com/watch?v=hBVJbzAagfs https://www.youtube.com/watch?v=hBVJbzAagfs

by bsaul 13y ago

volune 13y ago

IMO dependency injection encourages making very deep object graphs. constructor argument passing can be cumbersome, but jumping into new code it is much more clear, and it encourages you to write flatter code structures. i go without.

snikeris 13y ago

I think the point is that you don't want to be instantiating (and thus configuring) a dependency at the site where it is used. The code in class Foo should be limited to implementing Foo, not instantiating and configuring its dependency Bar.

wtetzner 13y ago
So why not just pass its dependency as a constructor argument?
- snikeris 13y ago
  Passing a dependency as a constructor argument is dependency injection: http://en.wikipedia.org/wiki/Dependency_injection#Constructor_injection http://en.wikipedia.org/wiki/Dependency_injection#Constructo...
  - wtetzner 13y ago
    Right, my point was more "why do you need a framework to call constructors for you?".
- UK-AL 13y ago
  That's what IoC containers do, or via setter. However a IoC container can automatically create, and send through the object based convention(IMessageQueue -> MappedTo -> MessageQueue) or configuration (IMessageQueue -> MappedTo -> APMQMessageQueue).

oh_sigh 13y ago

Not to sound snarky, but you should read any introduction to dependency injection. The benefits are generally covered very thoroughly, and what you said is not usually considered a benefit.

kyberias 13y ago
Wikipedia article on dependency injection, section titled "Advantages", _first_ bullet: "The result is more independent clients that are easier to unit test in isolation using stubs or mock objects that simulate other objects not under test." Would you like to try again?
- oh_sigh 13y ago
  The OP said "I mean, what's the point of being able to replace an implementation outside the source code itself." Where, in what you posted, does it reference being able to replace implementations outside of the source code itself? Would you like to try again?

deleted 13y ago

[deleted]

rymndhng 13y ago

It depends. One thing that I thought is an interesting feature of Spring, is that it allows the framework to inject code between your dependencies like decorators. This allows them to do aspect-oriented-programming transparently. And I think there's some interesting ideas here. For example, you can mark the interface of a class as @Transactional, and all your implementations will get the behavior.

UK-AL 13y ago
I think that's the interception way of AOP? Unity IoC in c# also does this. The IoC container will return transparent proxy(Not the original object), which then calls the underlying method(after doing the AOP behaviour).
- Glide 13y ago
  Be careful of using these though. I had an obscure bug using dynamic proxy (castle dynamic proxy2) a while ago in a WPF application. I was proxying to an interface so it created a proxy object in between that in the actual class so it was eating my C# event. Changing the proxying from an interface to a subclass fixed it. Boy that was a fun one to figure out.

twistedpair 13y ago

When you've got a complex graph of objects and dependencies between them, DI can easily take care of instantiating an A and feeding it to a B that requires an A and so on and so on. In our projects we'll have a DebuggerFooImpl, a MockFooImpl, and a ProdFooImpl. Spring's AppConfig classes then can create the proper object at startup based on environment profiles and no consumers have to do any more than ask for the Foo object to be injected into them, isolating them from any environment awareness/coupling. There are other benefits from DI as well, but the above at the low hanging fruit, isolating the complexity of object creation from the object's consuming classes.

Terr_ 13y ago

It tries to disentangle two different problems: 1. Does my class work appropriately? Does it encapsulate/hide/abstract the right behavior? Does it function correctly with other classes that implement certain inferfaces? 2. Is my network of classes correctly defined so that I can use them all together in a particular way? http://programmers.stackexchange.com/questions/92393/what-does-the-spring-framework-do-should-i-use-it-why-or-why-not/92672#92672 http://programmers.stackexchange.com/questions/92393/what-do...

ddeck 13y ago

There are definitely more advantages than just the unit testing side. The Google IO talk on Guice does a pretty good job of explaining the benefits: https://www.youtube.com/watch?v=hBVJbzAagfs https://www.youtube.com/watch?v=hBVJbzAagfs