Still trying to figure out what DI/IoC but are afraid to speak up?

CodeProject - Design pattern – Inversion of control and Dependency injection

• “Introduction
• The problem – tight coupling
• Solution
• Principles of IOC
• Ways of implementing IOC
• Implementing the DI
• What’s wrong with DI FACTORY?
• The container way
• Implementation using Windsor
• References
• Other Interview question PDF's

…
In this section we will discuss about how IOC and DI can help us build loosely coupled software architecture. I am not sure should we call this a design pattern or more of a approach. If you search around the web you will see lot of controversy on whether IOC is a design pattern or not. From my point of view it is a design pattern as it solves a problem context.
It would be great to see actual architectures implementing IOC using container oriented approaches. I am sure it will change the way we think about interaction between components.
So let’s understand in detail about IOC and DI.
…”

I’m not afraid to say it… I’m still trying to wrap my head around DI/IoC. There, I said it! I mean I get it but I am not sure I really "GET” it, know what I mean? (Note to Self: And I probably won't until I start coding with it, so start coding with it dummy!  ;)  (You can tell it's a Friday and I start talking to myself and calling myself a dummy... lol)

And I'd bet there's a silent developer majority our there who might be in the same boat as me. We've heard about it, seen few casts, read a few articles, but have yet to actually jump in...

The above Code Project has a few translation issues, but I liked it. I thought it presented one of the problems DI/IoC is trying to solve well and did a good job (with pictures! ;) explaining why DI/IoC is a good solution. The code samples, using Castle Windsor, are also easy to follow and understand.

This article will not be your only stop on the groking DI/IoC, but it's work a quick pitstop...