Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

First, I'm an entry level programmer; In fact, I'm finishing an A.S. degree with a final capstone project over the summer. In my new job, when there isn't some project for me to do (they're waiting to fill the team with more new hires), I've been given books to read and learn from while I wait - some textbooks, others not so much (like Code Complete). After going through these books, I've turned to the internet to learn as much as possible, and started learning about SOLID and DI (we talked some about Liskov's substitution principle, but not much else SOLID ideas). So as I've learned, I sat down to do to learn better, and began writing some code to utilize DI by hand (there are no DI frameworks on the development computers).

Thing is, as I do it, I notice it feels familiar... and it seems like it is very much like work I've done in the past using composition of abstract classes using polymorphism. Am I missing a bigger picture here? Is there something about DI (at least by hand) that goes beyond that? I understand the possibility of having configurations not in code of some DI frameworks having some great benefits as far as changing things without having to recompile, but when doing it by hand, I'm not sure if it's any different than stated above... Some insight into this would be very helpful!

share|improve this question
up vote 11 down vote accepted

The fundamental idea in DI is simply to push dependencies into objects, rather than letting them pull dependencies from outside. This was also called "inversion of control" earlier. This allows one to control dependencies much better, and - last but not least - to write code which is easy to unit test.

DI frameworks only build on top of this idea, and (partly) automate the often tedious part of wiring object dependencies together. This may otherwise require a significant amount of code in a larger project when done by hand.

To define dependencies, apart from external configuration files, it is also possible to use code annotations nowadays, e.g. in languages like Java and C#. These may bring the best of both worlds: wiring dependencies in a declarative style, but right within the code itself, where it logically belongs to. To me, the possibility of changing dependencies without having to recompile is not that valuable, as it is rarely done in real life (apart from some special cases), but introduces an often artifical separation of dependencies from the classes and objects defined within the code.

To return to your title question, DI is not an alternative to composition nor polymorphism; after all, it is made possible by these two.

share|improve this answer
Dependency Injection (DI) is a form of Inversion of Control (IoC). – Matthew Flynn Jun 1 '12 at 22:29
@MatthewFlynn, indeed. For reference: – Péter Török Jun 1 '12 at 22:41
That IS my reference. He talks about the new " lightweight containers" doing inversion of control, which was something that was already common as UI event listeners were a form of IoC. He dubs the object binding that Spring and other IoC containers do as Dependency Injection to differentiate it from the other form of Inversion of Control. – Matthew Flynn Jun 1 '12 at 23:07
Oops--I missed the "indeed." I thought you were contradicting me... Sorry. – Matthew Flynn Jun 1 '12 at 23:57
Your last paragraph makes me feel a bit better; the whole time I was working on my little learning project, I kept saying to myself, "this feels like polymorphism.." . Unfortunately, the .Net and c# at my job is horribly out of date, but from looking into it, is Unity the built in c# framework you are talking about? – Drake Clarris Jun 2 '12 at 2:32

The best article I've ever read on the topic was James Shore's. I've been doing "DI by Hand" for ages, as part of abstraction and polymorphism. So after I got into the professional world and I kept hearing that term being thrown around I had a large disconnect between what I thought the word should mean and what it actually means:

"Dependency Injection" is a 25-dollar term for a 5-cent concept.

That's from Shore's post, which cleared everything up for me. A bit further, though, DI frameworks provide the boilerplate to connect things up to one another.

That's it.

share|improve this answer
+1. I never really got DI until I read that article – matt freake Jun 10 at 7:30

I am not an expert as I only started using DI in the past couple of years, but a few of the useful themes/functionalities of DI containers that I've noticed are (which I don't think of as products of composition/polymorphism (but I may stand to be corrected on that):

  • central hub of object creation
  • provide singletons on a per thread basis
  • aspect oriented techniques such as interception
share|improve this answer

Apart from DI, there is a class composition configuration at the root application (instead of configurating using xml). There is no need for any DI or IoC framework, even though they can tidy up the class composition configuration, particularly for large projects. This is because the DI framework normally come with container that implement additional features, such auto-wiring, that helps to configure class composition. You can read my blog entry to extract my understanding on this topic.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.