Does anyone here use an automatic dependency injection framework? If so, how do you use it? I just looked at PicoContainer, a Java D.I. framework. My first thought was "this is kind of cool". My second thought was "but how and where should I actually use this?" It seems to me dependency injection is useful if you almost always use the same implementation of an interface in one context (for example a given application), but still want to give other people the option of supplying a different implementation in other contexts (other applications; tests), without paying the "abstraction tax" of manually passing the correct object to every constructor of an object that needs it in your current application. But D.I. doesn't seem to be that applicable to complex object relationships. For example, a hierarchical relationship where the children keep references to their parents (like Book <- Chapter <- Paragraph (yes, it's a silly example, but I hope you know what I mean).)

I personally strongly dislike these topics, and did so since they came out.

All frameworks I've seen lead to horribly un-intuitive code, along with some completely redundant workarounds for the most trivial of tasks.

This isn't to say they are wrong, or broken by design. But I've never felt the need to use them, where I couldn't find a simpler solution that covers all the needs.

And after the Agile movement died down, most of these concepts did as well.

Keep in mind this is my personal opinion. The concepts defined there are valid, and are used in some major products. but given the alternatives, I feel it's redundant, given the implementations provided. It's likely that there are simpler implementations which are more suitable for given problems.

But perhaps the greatest beef I have with this is that for me, it doesn't warrant a whole fancy big name thing. It's simply going back to procedural programming in OO world, where, instead of encapsulating functionality into an object, you pass it through functions. And that to me doesn't warrant some overbloated framework or a name in itself. It's just aproach that's sometimes useful in limited manner. It's same old thing, re-invented under a new name.

Yes, the term is a bit pompous. But just because something is hyped doesn't mean that it's bad (although the hype may lead to overuse, which *is* bad). While passing in functionality isn't a new idea, doing it in an *automated* way is (to the best of my knowledge).

Just one thing to keep in mind, is that this pattern didn't emerge because it would be great or useful.

It evolved from TDD, so that each part can be tested without any kind of dependancy whatsoever at any point during life-time of project. Ever. No dependency.

Most of the time, it's simply too unwieldy, or too independant. Frequently you just need your application to do what it needs to do.

This is the pinnacle of test driven design. Where methodology starts driving the development. This aproach is the final step of an ideology, and as such, is too radical to outweigh the benefits.

Dependency injection didn't evolve out of need of users, developers or customers. It solves the problem of complete unit testing, and complete TDD. If those are your primary goals, then this aproach is viable.

Perhaps two most notable examples dependency injection frameworks include Spring framework and JBoss. The later, while it does (I guess) still have a following has gained popularity through an incredibly controversial social engineering and marketing drive which due to an accident was exposed. It never justified its merits. And as far as Java web frameworks go, Ruby has replaced them.

My conclusion to this is, that while this type of big picture design is viable, it has so far not been proven to be warranted by any marketable project due to its merits alone.

And going for something fancy can be dangerous.