You should consider looking closely at Hivemind, which is a very nice IOC framework that avoids the mess Spring configuration can be, in an elegant way.

Let me reflect: I think you’re saying that IoC is all about functional decomposition. And that people are using IoC at too low level of granularity.

But who defines what a component is? It seems like a subjective decision, like deciding whether a virus is “alive” or not, or whether chimpanzees are “intelligent”. Is this the role of an “architect”?

Secondly, how do you respond to cross-cutting concerns; design constraints such as logging, security, remoting, asynchrony, transaction control, new domain models, etc.?

Objects have two responsibilities – the first to its callers, and the second to the environment in which it operates. So I like IoC as a way of a class declaring to the world to “treat me like an object”. Objects need to become more “environmentally” aware.

Now I think that your discussion of interface vs. implementation misses out on one of the core OO concepts: message passing. Even in the early stages of a project, injection is not just about functional decomposition, it is about deferring choices of the medium through which a message can pass. Some people call this “context”.

By using IoC only at the component level, you prevent control over the fine grained message passing, and this leads to cross cutting concerns being implemented in multiple places.

Anyway, a few points:

- Using classes breaks the whole concept of IoC, and
- …leads to the Impl smell, you know the one, where every single class has a corresponding interface

Both these statements imply a code-base in transition. The first: an interface hasn’t been defined yet, but at least there is a seperation of complexity. But even when injecting classes rather than interfaces, you still don’t guarantee the actual implementation. There are various interceptors that can sit between the class under test and the injected class.

The second: Once you’ve defined an interface, you only have one implementation. But one assumes that you’ve introduced an interface for a reason.

- Castrated version of Spring IoC…

It wasn’t just programmatic configuration of Spring. It was the use of a fluent interface to express the wiring. Given that we’d changed container at least once on the project, I think this was quite elegant.

-…in which you could only use name based constructor Dependency Injection

Spring supports multiple patterns of injection, but I think it’s ok to narrow this down on any given project so that there is a consistent metaphor. In this case we are enforcing the “Good Citizen” concept. But exceptions are still possible…

-I think IoC should be really carefully thought out and avoided until the design has been considered more

I’ve always felt that “Design” isn’t a thing. It is a process. Thus talking about the “design” is a bit like talking about the “integration”. I think that design is about considering options. At the end of a good design process you have something that satisfies all the constraints. So let’s do it all the time. But lets use consistent metaphors to enable that design process, in the same way that we can use TDD as a standard approach the unit, integration, and acceptance levels

-Have you tried using dependency injection without a framework? What benefits does Spring bring over just using the “new” operator?

IoC, being sort of a glorified Factory Pattern, offers most of Factory’s benefits. For instance, single point of replacing, say, XmlRepository with a HibernateRepository implementation to Repository. Imagine if XmlRepository has been instantiated using ‘new’ all over the place. This should also apply to your second question.

On stubbing external dependencies… Yes, it’s not a silver bullet and should be used with caution. However, if the system has been well designed, the internal implementation of the stubbed class’s services should not affect the stub and certainly should not affect the test that’s making use of it. If it has a method, getTotal() which is being used by the class under test, it’s just the result of this method that we care about and the way this is being calculated should not matter in the scope of the test in question.

- … Does it help you higher-quality systems quicker?

IMHO, it does help organize the codebase and replace components’ implementations with little pain. This replacement is not required that often, but when it is, Ioc can play a major role to an easy transition.

I suspect you already have your version of the answers to the above questions, and I would really like to hear it.

-Have you tried using dependency injection without a framework? What benefits does Spring bring over just using the “new” operator?

- Did the people who trying to programmatically configure Spring consider just using the “new” operator to manually wire their objects together?

- With regard to, “I much prefer stubbing them out by extending them in a private class inside the unit test and make them behave as I would expect to”, have you had any problems maintaining code that uses that technique a lot? What do you do when the class that you’ve stubbed out changes and you then have to track down all of it’s sub-classes in the tests?

- With regard to, “Spring has become as indispensable to ‘Enterprise’ projects as an application server”, do you think this is a good thing? Does it help you higher-quality systems quicker?