Poor use of DI versus need for DI

Agreed, if you are calling Container.GetService or something similar all the time then that really isn't "Injection".  Well, other than the fact that you save satisfying the dependencies of that dependency.

Having a bunch of classes with a dependency on ServiceLocator or some custom IoC static class is definitely a code smell.  You shouldn't need to call on the container anywhere but perhaps in the bootstrapper code.

Heh, I was also mildly surprised at the "hand rolled mocks" preference.  Though both of these comments may be more of a personal preference rather than a reflection on Java.  Some people prefer hand-rolled cigarettes too.

Pingback from  Twitter Trackbacks for                 Poor use of DI versus need for DI - Jimmy Bogard - Los Techies : Blogs about software and anything tech!         [lostechies.com]        on Topsy.com

I couldn't agree more.  Dependency Inversion is about managing dependencies, about reducing coupling.  I won't beat the dead horse that are the benefits of doing this; but exchanging one coupling for another (changingg a coupling from direct construction of one of your internal classes to use of an inversion container) doesn't get you the full benefit.  Sure, you're now coupled to something more stable; but you're still forcing the responsibility (and thus coupling) of creating these objects via the container on to types that shouldn't have this responsibility.

There should be very little calls to the IoC to create or initialize an object.  You'll need at least one; but if all creation/initialization of your objects involves a direct call into the IoC, you haven't designed for DI; you're simply using a DI container.

A number of people have pointed out that my example was so simple as to be meaningless.  I think that's funny because, I took the example from the Guice tutorial.  In any case, I wrote the post because I have seen a fair bit of code lately that exhibits the problems I was talking about.  The fact that some of us know how to use a DI container does not mean that a vast number of developers aren't out there abusing them.

Well balanced response.  I can definitely see your point here.  I will check out FubuMVC.  I have seen a large amount of hard to understand code due to overuse of IoC containers, but that doesn't mean they can't be used correctly.  I think the core problem is we have so many containers and frameworks.  I would like to see a language built around this core idea.

Wow, that was a great article.  You very eloquently described the situation perfectly.

This post was mentioned on Twitter by lostechies: blogged: Poor use of DI versus need for DI: Surprise surprise, but Uncle Bob got the twitterverse all riled up wit... http://bit.ly/5eOiyn

I totally agree with your article.

There are in my opinion however some valid scenarios where a call to "container.GetInstance()" makes total sense, for example when the instance to retrieve implements IDisposable.

In that case, you do want to dispose the object as soon as you are done with it and construction injection is not enough.

A call would typically be

using(var objectToRetriever = container.GetInstance(IDisposableObject))

{

//do stuff here

}

unclebob: "A number of people have pointed out that my example was so simple as to be meaningless.  I think that's funny because, I took the example from the Guice tutorial.  In any case, I wrote the post because I have seen a fair bit of code lately that exhibits the problems I was talking about.  The fact that some of us know how to use a DI container does not mean that a vast number of developers aren't out there abusing them."

Examples in a tutorial tend to be simple (easier to grasp the concepts).  I you want to prove DI can go bad you may want to use a more realistic example (as you say... you have seen a fair bit of code lately that exhibits the problems => create an example based on that code)

Still... everything pattern can be used and abused.  Bad DI is bad, good DI is ...?

@Michael Sevestre : in such a case, shouldn't you take a dependency on an IDisposableObjectFactory instead ?

Every time you take a dependency on the container, you're basically saying that this class may instantiate pretty much any other class, and therefore no longer controlling your dependencies.

It seems in fact that Uncle Bob was railing against this particular kind of "leaks".

Cheers,

--Jonathan

Excellent response. I agree that this is an (exceptional) case where it's best to respectfully disagree with Uncle Bob.

Thank you Jimmy for responding.

I'm definitely with all of you on the "less code" argument. But two more points if I may, mainly to clarify my own understanding :

1. When you do need the container, as you said the class takes an explicit dependency on it ("container" constructor arg, perhaps). Very good. So can we all agree that the often seen "IoC" global variable is an anti-pattern ?

2. For the particular case, described above, of a class that must lazily (and/or multiple times) instantiate a class whose type is known at configuration time (i.e. we're not writing a ControllerFactory), when I suggested using a factory I was not thinking of writing it manually (and my hint of a named factory interface was misleading in that respect). What I would actually do in that case is add a Func<IDisposableObject> constructor argument, very easily configured with a lambda that captures the injector as a local variable, like so : ()=>injector.Create<IDisposableObject>()

I believe this keeps the dependencies under control for a modest cost.

Hoping this makes some kind of sense,

--Jonathan

Pingback from  The Morning Brew - Chris Alcock  » The Morning Brew #521

Interested by your little swipe at Java mocking tools (agree about the lang). I'm not a Java guy (in any way), but I've been very impressed with Mockito (much like Moq), have you seen it? Even JMock has improved a lot over the years and whilst I find it slightly opaque compared to Moq (& mockito) & more of a PITA, I don't think the state of it can properly explain Bob's love for writing his own mocks (too many Kata's creating a strange love of small, simple, pretty things might).

Good response to U.B. though - fully agree with your general sentiment, just intrigued by the mock bit.

Pingback from  Elegant Code » Being provoked by your uncle

Pingback from  Week @ Lab 2/13/10 « Tech Tock