2

For a long time I've been designing applications using Interface/Inheritance based polymorphism, to gain loosely coupled code. As far as I can see (so far) DI frameworks/IoC merely provide tools to make this "easier", however, the additional level of abstraction seems to be redundant and costs you additional overhead.

The only reason I can think of is if a large team already know a particular DI/IoC framework then everyone can be on the same page.

From my perspective, DI seems to be doing the same thing as design by interface, I hope there's more to it than that, could anyone explain to me why using a DI/IoC framework is a better strategy?

I really hope I've got it wrong about DI/IoC.

Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
ocodo
  • 29,401
  • 18
  • 105
  • 117

2 Answers2

6

Firstly, can you read this required reading and edit in any missing points from there...

If you're expecting DI containers to a) be extraordinary complex beasts or b) a whole new design paradigm, I reckon you're reacting in the normal defensive way one approaches an over-hyped concept.

While one can invest a lot of effort into using DI containers in all sorts of arcane ways, and there's lots of power in there wrt overlaps with AOP etc., the typical sweet spot is for straightforward auto-wiring of dependencies without any "all the team needing to understand" anything or "overhead" (do you mean conceptual or perf? If the latter, have you measured the impact in an actual app?).

But do understand this:- the freedom and focus on clean design enabled by the reduction in friction and increased malleability resulting from you chucking away a lot of boilerplate code (and the necessity to rejig it if things change) IOC containers are for me a critical part of a development ecosystem. While they're only doing a few news here and there, their impact is not in proportion with the actual (small) bit of work they're doing.

As for whether they're different to normal interface based programming and good design principles, I'd view them as something much smaller - a tool that enables just one of the SOLID principles.

Community
  • 1
  • 1
Ruben Bartelink
  • 59,778
  • 26
  • 187
  • 249
  • 1
    Thanks, that's pretty good, by overhead I do mean conceptual, I realise that there is a very small perf' hit, but for my general application domain it's negligible. - By the way, I'm considering using Ninject (C#/.Net) on a new project. – ocodo Nov 21 '10 at 00:41
  • @slomojo: In that case, as long as you dont go mad on [ab]using all sorts of trickery that containers like to throw at you without analysing the cost/benefits properly, one can view DI containers as automating writing chains of new statements to make your code more malleable. The only thing the average developer needs to understand is the DI Bindings. But even doing that much will gain you much in terms of people having to consciously think about couplings across areas of your system. – Ruben Bartelink Nov 21 '10 at 00:48
  • 2
    @slomojo: Also @Mark Seemann (recommend reading his highest rated posts around here if you want good DI advice) has a book coming out soon (already in electronic MEAP form) I'm looking forward to myself - http://manning.com/seemann which may be of benefit to you. It'll cover all the subtler patterns involved in dependency management in general (together with treatments of specific containers). Hopefully others will chime in with some info too. – Ruben Bartelink Nov 21 '10 at 00:50
3

No, DI/IoC is not the same thing as designing by interface.

A DI/IoC engine is really just a big instance factory. It saves you from having to write and maintain your own.

The benefits are less maintenance (you don't have to write it) and a larger audience to find and report bugs. If the team that wrote the DI/IoC engine is better than you and your team, you get to use higher quality software. And if you choose one that is in wider circulation than your home-grown solution, there's a chance that outsiders will know how to use it from reading books that are widely available. People on your team will have their resumes enhanced by knowing and gaining experience with a well-known framework.

I'd encourage you to continue to design to interfaces, but there's more to DI than that.

duffymo
  • 305,152
  • 44
  • 369
  • 561