It took me quite a lot of time to get my head around the Dependency Injection pattern. Getting a simple answer to the question "what is Dependency Injection" is not easy. And when you think you "get it", you'll come across an article or a statement that confuses the issue.
So I was happy when I found this citation on Andrew Binstock's blog:
"Any nontrivial application is made up of two or more classes that collaborate with each other to perform some business logic. Traditionally, each object is responsible for obtaining its own references to the objects it collaborates with (its dependencies). When applying DI, the objects are given their dependencies at creation time by some external entity that coordinates each object in the system. In other words, dependencies are injected into objects."
I don't think you can put it simpler than that. I'll be writing more about Dependency Injection as part of my series on TDD so I'll return and try and show with some examples how to use Dependency Injection and give some good reasons why you may want to use it.
The confusion around this topic stems, I think, from the fact that Dependency Injection is almost always discussed in the context of a Dependency Injection framework such as PicoContainer or Spring. These frameworks are no doubt very useful, but I don't think bringing them into the mix when explaining the pattern adds value to the discussion.
The definitive article on Dependency Injection was written by Martin Fowler and I recommend reading it despite it's use of various frameworks in its examples.