Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Why was the dependency injection pattern not incluided in the gang of four? Did GOF pre-date widespread automated testing? Is dependency injection now considered a core pattern?

share|improve this question
14  
.. because "Dependency injection" is not a pattern! –  Dipan Mehta Feb 20 '12 at 12:51
1  
@DipanMehta stackoverflow.com/questions/823387/… –  Tom Squires Feb 20 '12 at 12:53
12  
Everything that gets repeated forms a pattern of repetition. All design elements (that aren't unique, crazy ideas) are "patterns". –  S.Lott Feb 20 '12 at 13:31
    
Books are always products of their time. I'd lay good money on it (and the closely-related IoC) being a key pattern if you were doing such a book now. –  Donal Fellows Feb 21 '12 at 10:48
3  
These long responses are probably misleading, as they kind of validate the question. While, as mentioned, dependency injection is not a design pattern. It is a "mechanism" for object instantiation, typically handled by the framework. –  Nazar Merza Oct 23 '12 at 17:33

4 Answers 4

up vote 67 down vote accepted

I was Editor of Software Development magazine when the Gang of Four book came out and I can say with total confidence that unit-testing was not a widespread practice in 1994, when Design Patterns was originally published.

In 1994, C++ was the most commonly used object-oriented language, and most people programming it were coming from a C background. One of the "thinking in objects" things that people simply didn't have is the idea of hundreds or thousands of entry points into your program. You thought about the main(). If you worked on a large project, you might have a (usually quite elaborate) makefile to create a module-based program. But "unit-testing"? Starting a process, building the necessary memory context, executing it, and tearing it down, on a per method basis? That was very radical.

Java made multiple-entry-point programming more obvious. By the time of the original Dot-Com boom, unit-testing was a well-known technique, but it was really JUnit (circa 2001?) that caused it to catch fire and become a universal practice.

Although Strategy and the general concept of programming to an interface were part of GoF and the mid-90s zeitgeist, the idea of injection came quite late to the party (circa '03-'05?). Honestly, my gray hairs are still quite dubious about that aspect of DI ("Get off my lawn, you darn configuration files!").

share|improve this answer
3  
+1 Informative and actually answers the question. –  dacamo76 Feb 20 '12 at 23:44
11  
I regret that I only have but one up vote to give for such an insightful answer. –  user8 Feb 21 '12 at 0:54
    
@Larry OBrien: scanning for convention based registrations vastly simplifies configuration code and practically eliminates xml configuration in ioc containers. –  qes Feb 21 '12 at 3:36
3  
I would like to add that dependency injection at its core does not rely on configuration files at all. You can do it all by hand, which makes it very easy to use and is still a very flexible approach. –  marco-fiset Oct 23 '12 at 14:34

They called it Strategy.

Their Strategy seems to have all the features of dependency injection without the complex-sounding name.

share|improve this answer
14  
-1. Sorry! Strategy pattern has nothing to do with Dependency Injection. –  Dipan Mehta Feb 20 '12 at 12:50
17  
12  
@Dipan: before going to downvote this, you better think about the answer five minutes. –  Doc Brown Feb 20 '12 at 13:20
5  
it's true that Dependency Injection can be considered very similar to the Strategy Pattern, but when people say dependency injection they usually mean Inversion of Control, which I think is a lot more distinct from Strategy (esp. IoC container). –  MattDavey Feb 20 '12 at 13:38
7  
DI is more of a creational pattern. It creates and injects strategies. Saying it's a strategy is just half the truth. DI is more a microkernel pattern! I can't believe people upvote this. Strategy is more like a trait of good DI, not a necessity. –  Falcon Feb 20 '12 at 17:52

First i would like you to reference Dependency Inversion Principle. Here is a reference from Object Mentor, : The Dependency Inversion Principle

According to this,

A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.

B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS.

The document cited above shows a good example that a Copy module while itself is abstract one, depends on lower level details of source and destination type breaking this principle.

When design evolves, one must check whether this principle is violated. The simple way to test the virtual class against DIP is to create, inside a unit testing framework a pluggable class. Ideally, i would plug such a class - that the base class shouldn't have heard-of or designed for. If the primary functions works as expected - it means that base class is reasonably abstract and doesn't quite violate DIP!

This process of injecting such a class to test is Dependency Injection. As wikipedia says

The pattern is particularly useful for providing "mock" test implementations of complex components when testing;

There is no one way to apply dependency injection; it can be done in many was and mostly it would use some other pattern itself.

According to me it is a well understood method for a particular task; but not really so unique that it be called a pattern of it's own.

Here is another great example which explains what is Dependency Inversion Principle and shows how a unit test framework is used to uncover this!

TDD-Design-starter-kit-dependency-inversion-principle

share|improve this answer
    
+1 for making a good argument, regardless if you are "right" or not. –  maple_shaft Feb 20 '12 at 14:29
    
Please revise your answer to answer the question, this is mostly a comment to another answer. The question itself has no reference to the strategy pattern. –  Yannis Rizos Feb 20 '12 at 14:36
    
@YannisRizos I appreciate your point. I was quite intertwined around the discussion. For the purpose correctness, i wouldn't mind doing this; can you guide me on editing this? –  Dipan Mehta Feb 20 '12 at 14:42
4  
Answer the question like you've never read the other answer. Tell us why you think the dependency injection pattern was not included in GoF, your thoughts on not being a pattern would be a valid answer (wrote "pattern" as in the question, not taking sides here). Then, if you really must comment on the other answer, please do so in a less aggressive tone. I feel you've expressed your disagreement adequately with your downvote and subsequent comments, so there is really no reason to include any reference to the other answer in your own. The community will decide which answer is "better". –  Yannis Rizos Feb 20 '12 at 14:49
3  
-1 The original question is about Dependency Injection, but you discuss Dependency Inversion. Not the same thing. –  Andres F. Feb 20 '12 at 15:42

I think Dependency Injection is more relevant when separating implementation in tiers. Another area where we think about dependency injection is unit testing. And your pre-date suggestion seems to be correct. If the gang were to collect and segregate patterns in 2012, definitely dependency injection will be there.

Strategy could come up in discussions but Strategy does not talk about dependency injection. But when using strategy pattern in a single project or dll(all classes and interfaces remain in one project) it appears that we are doing dependency injection. In fact we are not.

Now, if the classes and interfaces mentioned in strategy pattern are separated in different projects or tiers then WE will have to use dependency injection techniques. We could use unity configuration files(no runtime change possible though). But Strategy pattern does not say how to inject a dependency.

If there is a pattern that resembles closely to Dependency injection then it is Abstract Factory Method pattern. This pattern could be used inside a strategy pattern to inject dependency.

share|improve this answer
2  
This doesn't answer the question. Please read the original question instead of replying to other answers :) –  Andres F. Oct 23 '12 at 14:32
    
Thank you for pointing out, I have corrected it. –  Blue Clouds Oct 24 '12 at 22:42

Your Answer

 
discard

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.