I finally get it - Dependency Injection

So for the past few years I've been reading about Spring, Inversion of Control and Dependency Injection and although I understood the inherent advantage of dynamically wiring things together I never really had an application that required or even suggested a need for that level of dynamism (is that really a word?).

Frankly, I'm embarrassed to say I didn't "get it" because I really didn't see the application of this pattern/idiom.

Then a few days ago I finally got around to listening to the first Google Developer Podcast and in it the hosts interviewed Bob Lee of Guice fame.

Finally his explanation of Dependency Injection (DI) clicked for me as to WHY I would use it.

"Dependency injection . . the reason for doing this is because it makes your code more testable, and results in a little less boilerplate code"

Finally *that* made sense. I guess a few things have come together to help me - I've been reading a lot about Mock objects and started using them a bit in my unit tests, plus I have been trying to figure out how best to express pretty generic business flows with objects whose complexity can vary considerably (different customers might need varying amounts of data associated with each business action).

For example, a simple thing as a book purchase could have an object with hundreds of attached data fields depending on many requirements - new or used book, reporting etc. There are also many actions available. The best way to handle such flows, I'm thinking, is to have an Interface (IOrder.java) and then pass it in to some piece of code that is aware of the flow.

Here's a simple possible example . . . .

public void execute(IOrder myOrder) throws OrderFlowException

{

if(myOrder.validate()) {

myOrder.execute();

}
}

Then the end customer can create their own implementation / override a default, with their own fields, just as long as it satisfies the interface.

I guess too many of the previous articles I read were a bit too much "Silver Bullet" oriented - which makes me gag! But often this bit about reducing dependencies just didn't sit right - logically if there's a dependency then there's a dependency! The core dependency is still there so that's not a silver bullet!

Yes Dependency Injection helps reduce dependencies between implementations but that's less than one-third the battle to getting to loose coupling IMNSHO. On the downside, extra layers of indirection just make your code hard to understand and the dependency still exists (at runtime).
Anyway, kudos to Bob Lee as his description was something I could "buy" - DI is something that makes my code more easily unit testable and which reduces boilerplate code. Makes another nice tool for my toolbox (not a whole new toolbox by itself!).

Perhaps I'm still a little lost (I still don't get the big deal) but not so totally anymore.

Anyone else as lost on this topic as me? Any resources I should read to help get up to speed? Or perhaps I should just dive into Spring / Guice and get it over with :-)