Dependency Injection Addiction?

Question

Is there a down side? I feel almost dependent on it now. Whenever a project gets past a certain size almost feel an allergic reaction to standard patterns and immediately re-wire it with a Dependency Injection framework.

The largest issue I've found is it can be confusing for other developers who are just learning it.

Also, I'd feel much better if it were a part of the language I was using. Though, for Java at least, there are a couple very lightweight libraries which are quite good.

Thoughts? Bad experiences? Or just stop worrying about it?

---

[EDIT] Re: Description of Dependency Injection itself

Sorry for being vague. Martin Fowler probably describes it FAR better than I ever could... no need to waste the effort.

Coincidentally, this confirms one point about it, that it's still not widely practiced and might tend to be a barrier when working with teams if everyone is not up to speed on it.

Answer 1

The only down side I can think of is tiny performance decrease through constant virtual calls :)

Answer 2

Could you add a link or two to explain what Dependency Injection actually is, for those of us playing along at home? The wikipedia article is entertaining, but not very enlightening.

Answer 3

I've taken a stab at describing some of the possible downsides in a blog post here: http://kevin-berridge.blogspot.com/2008/06/ioc-and-di-complexity.html

Answer 4

In my opinion, the major drawbacks are the learning curve (as you point out) and the potential for the added abstraction to make it more difficult to debug (which is really part of the learning curve as well).

To me, DI seems to me to be more appropriate for larger, complex systems -- for small one-off apps, it may result in the app being over-architected, basically, having the architecture take more development time to adhere to than it can ever make up for in the value it provides.

Answer 5

I am big beleaver in IO however I see some projects with huge xml configuration files which no one understand. So beware of programming in xml.

Answer 6

@Blorgbeard: http://www.martinfowler.com/articles/injection.html is probably one of the best articles on the subject

Answer 7

Just stop worrying about it. It's my opinion that in time IoC techniques will be second nature to most developers. I'm trying to teach devs here at work about it and I find it difficult to get the message across because it feels so unnatural to the way we've always done things.. which just so happened to have been the wrong way. Also, developers both new to IoC and new to a project I find have an even more hard time. They're use to using the IDE to follow the trail of dependencies to gain an understanding of how the whole thing "hangs together". That information is often written into arcane XML.

Answer 8

Also, I'd feel much better if it were a part of the language I was using.

FYI there is a very simple and functional dependecy injection as part of JDK 6. If you need lightweight, straightforward dependency injection, then use it.

Using ServiceLoader class you can request a service (or many implementations of the service) based on a class:

 package dependecyinjection;  
 import java.util.ServiceLoader;  

 public abstract class FooService {  

     public static FooService getService() {  
         ServiceLoader<FooService> loader = ServiceLoader.load(FooService.class);  

         for (FooService service : loader) {  
             return provider;  
         }  

         throw new Exception ("No service");  
     }  

     public abstract int fooOperation();  

 }  

 package dependecyinjection;  
 public class FooImpl extends FooService {  
     @Override  
     public int fooOperation() {  
         return 2;  
     }  
 }

How does ServiceLoader defines the service implementations that are returned?

In your project folder create a folder named META-INF/services and create a file named dependencyinjection.FooService. This file contain a line pointing to the service implementation. In that case: dependecyinjection.FooImpl

This is not widely known yet.