Comments on Captain Debug's Blog: The Benefits Of Dependency Injection

A link to this simple, seemingly uncontentious blo...

2011-10-19T21:23:02.314+01:00

A link to this simple, seemingly uncontentious blog was posted on Reddit a few days ago. This generated about 6000 page hits and over 200 comments. It just goes to show that there are as many opinions as programmers; however, the the consensus, with which I agree, seems to be in favour of DI, although I'm promising myself that I'll get around to checking out OSGi - one day.

Wow, a lot of hate for DI here! I've worked...

2011-10-19T21:10:16.275+01:00

Wow, a lot of hate for DI here!

I've worked on several projects that wrote their own object configuration factory based on XML and/or annotations (and one I wrote myself). This was in pre-Spring/CDI days, and they served their purpose well. It isn't that hard... at its heart Core Spring doesn't do anything particularly clever; IMHO the real value of Spring is in its vast ecosystem. That to one side, I do think it's pretty hard to argue CoreSpring/DI/IoC doesn't bring any benefits over using new Impl(), even if you don't think they out-weigh the trade-offs (the indirection, arguably greater complexity and the everything-is-a-singleton trap). DI/Spring makes it really easy to wire your app in different ways to support different configurations, which amoungst other things, does have obvious benefits for testability as Roger pointed out. Accepted that's more important to some than others.

As an aside: if peeps have worked on sucky projects that use Spring, don't blame Spring or the DI pattern, blame the architect or the developers. Bad workmen, tools and all that.

What I really want to say though is: don't assume DI/IoC is the end game for achieving proper modularity and all the benefits that brings. You're still coupling interfaces with their implementations, you're just doing it within an XML file or annotations rather than via new Impl(). For that you need a broker, and in this space OSGi is still pretty much the only game in town. Services-First Migration to OSGi was a good passionate talk on this at JavaONE. There were several others.

I used Spring for about 3 years. DI and Spring _ca...

2011-10-18T17:39:15.760+01:00

I used Spring for about 3 years. DI and Spring _can_ be useful for testing, I agree.

Spring as an implementation is far from optimal. I think this is more an artifact of DI/AOP/etc not being natively supported by Java.

I've spent countless hours trying to figure out the xml incantations to get things to work as expected.

Santiago, You do not need a DI framework to do DI...

2011-10-18T13:42:46.312+01:00

Santiago,

You do not need a DI framework to do DI. Your use of factories is still DI. DI is just injecting dependencies into a class rather than the class instantiating its own dependencies.

"The idea of communicating objects through public interfaces and exchanging backing implementations is older than DI, and perfectly plausible without it."

That is DI. Just because you don't use an IoC container like Spring doesn't mean you are not doing DI.

I come from PHP and Zend Framework where they use ...

2011-10-18T11:26:08.137+01:00

I come from PHP and Zend Framework where they use DI to good effect, being able to plug and play aspects of a framework is nice (config files: PHP array, Yaml, Xml, Ini) etc is nice... DI seems to depend on what level you are in the software stack, if you are the glue level then it has it's place

There are no benefits to DI. There are no design ...

2011-10-18T09:56:43.439+01:00

There are no benefits to DI.

There are no design advantages to using DI.

The belief that "it is ok to partially construct objects" and spring will sort it out later on is complete bullshit.

This allows programmers (especially the weaker ones) to write code without first thinking, which ultimately ends up in project disaster.

Don't use DI.

You will find that without DI you will be writing less tests, and therefore, concentrating on getting your job done rather than noncing on about agile practices.

I'm with Anonymous here, I never saw real bene...

2011-10-17T16:20:11.656+01:00

I'm with Anonymous here, I never saw real benefits to DI.

The idea of communicating objects through public interfaces and exchanging backing implementations is older than DI, and perfectly plausible without it.

The amount of code you write is roughly the same, or more for DI frameworks that need heavy configuration, only now the actual logic that drives instantiation is hidden from sight. I'd much rather have a plain-old factory for the classes that I actually plan on interchanging, and put that logic where it belongs -- right were the next programmer to read my code will need it to know what's happening.

Yeah, DI feels automatic and magical, but magical also means mysterious, and I don't like my code being mysterious.

DI copes the wiring of static dependencies. And pr...

2011-10-14T11:00:16.296+01:00

DI copes the wiring of static dependencies. And preferrably it does this via Constructor Injection.

This brings in two issues: First devs regullary mix dynamic dependencies (i.e. sth. like a Tx) with static dependencies (Statless Service A depending on a stateless Service B).And the other thing is: Is it really so beneficially to get some services injected vs. retrieving those frome some service provider?

I don't think you write less boilercode with DI. I'd rather say, unless you fragment you solution into hundreds of individual & stateless services, you even write more boilercode and esp. much more complexity compared to a simple ServiceFactory which simply readss: ServiceProvider.get(ServiceInterface.class).doServiceA().

The last pro-DI resort would: "It helps desigining better software". Frankly meanwhile I do think: None at all!

Good software means loose coupling via interfaces. Isolatable units which can be unit tested. Clear, simple and eady design and architecture contracts. I've seen to much really grave design error provoced by the developers idea that DI will "magically" know and do the right thing and rather places where I'd the impression DI helped to achieve a better software design.