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.

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.

So why not just pass its dependency as a constructor argument?

Passing a dependency as a constructor argument is dependency injection:

http://en.wikipedia.org/wiki/Dependency_injection#Constructo...

Right, my point was more "why do you need a framework to call constructors for you?".

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).

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-do...

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.

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.

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).

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.

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

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?

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?