When is Poor Man’s Dependency Injection appropriate?

When is Poor Man’s Dependency Injection appropriate?

Only in legacy code situations.

That’s it.  I was called out appropriately on forgetting this, but legacy code, where I have to apply dependency-breaking techniques, does not always afford the opportunity to apply Dependency Injection and IoC properly.

Perhaps another question would be – for what situation would it be appropriate to apply the Dependency Inversion Principle, but NOT DI and IoC?  For me, just one class implemented with PMDI is pain over using an IoC container.

If your application is so small that PMDI seems appropriate, then why bother at all?  Why not use RAD tools, go for a Linq2Sql backend, and slap it all together in a controller action?  If my app was so small that IoC is too much, there are LOT more optimizations I’d make towards that end.  If my app was so small that it won’t change enough to need DIP, then who cares?  I’m wasting the business’ money otherwise.

Also, I do not buy the legal argument.  If you can only use Microsoft products, then use the Microsoft container, Unity!

Classes should be very clear on what they do, and what they require to function.  If I see two constructors, one without arguments, this would imply the overloaded parameter-ful constructor contains optional dependencies, not required dependencies.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Design. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • I can think of one other – in training. Showing PMDI as an introduction to DI is hugely accessible – pretty much everybody gets the concept straightaway. It’s then pretty easy to show how it degenerates so quickly, which really makes them appreciate what an IoC is bringing to the table.

  • Michael

    I can also think of another one: writing components that should be used as “black box” in other applications? You do not necessarily want to have the users of your component having to cope with all the mandatory wiring to get the component working.

    What’s your view on that subject?

  • @Michael

    Honestly, I don’t really have one – I’ve never been in that situation.

  • Bryan Watts

    @Michael: Hard-code the wiring into the component’s entry point. Black-box exterior with DI goodness.

  • smurf

    what’s about custom attributes?

  • Perhaps a more apt name for the pattern being described would be “Specification-only Dependency Injection” given that this pattern manifests itself in projects which employ unit testing without relying on Dependency Injection during normal use, and because no dependency injection is performed during the application’s normal use … poor or otherwise.

    Concerning the question of appropriateness, I might consider this pattern acceptable for new development in some circumstances, perhaps for small utility applications, etc., but such an approach should certainly be reconsidered at the point more flexibility is realized, or when the size of the application starts to grow beyond the size that a moderate refactoring session could alleviate.

    I would also say it’s an acceptable pattern for tutorial applications, spikes, or prototypes (unless it interferes with the objective of the application), but if an application is purposed as a reference implementation then it would be more appropriate to show real-world usage scenarios.