CODEWITHSUNDEEP
dependency-injectioninversion-of-control
ocodo
ocodo

Reputation: 30319

Design by Interface vs IoC/DI

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.

Upvotes: 2

Views: 385

Answers (2)

duffymo
duffymo

Reputation: 309028

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.

Upvotes: 3

Ruben Bartelink
Ruben Bartelink

Reputation: 61903

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.

Upvotes: 6

Related Questions