Pros:
Doesn’t pollute constructor with more then one parameter (replacing constructor injection).
We have a consistent use for all classes so we don’t have to think about it and thus decreasing our cognitive load when programming.
We may be able to remove some factories.

Cons:
Simple classes may be a tad more complex.
It will have to be combined with a mock library.
It may be harder to understand testcases before you know the approach.

I bet there is something i have missed… :-)

public abstract class AbstractJimi {
protected abstract Guitar createGuitar();
private Guitar guitar = createGuitar();
…
}

pubilc class Jimi extends AbstractJimi {
protected Guitar createGuitar() {
return new Guitar();
}
}

Still not as ‘clean’ as you’d like, I know, coming with the cost of an extra class. But it does allow you to mock Guitar in a unit test without reflection, and it doesn’t require a factory interface/mocked factory/factory implementation trio. I think this one just comes down to preference at this point.

-Matt McGill

Which is why I originally decided that setting the things through reflection in tests was better than messing up my classes by introducing a PaymentBuilder interface with a DefaultPaymentBuilder, PaymentBuilderImpl or something equally nasty. Which also suggests that we might acutally want to replace the builder classes with a different implementation later (which we never will, because there should only ever be one way to make a Payment from a PaymentDocument).

*takes deep breath, steps away from the keyboard*

Please excuse the huge volume of posting- I’m sure this can be explained in less words.

…for which I think they’re great.

> Your example is a Domain object…

You’re right. This is an inappropriate use of IoC, and that’s the point.

A more real-world example would be this:

class PaymentService {
    private PaymentRepository paymentRepository;
    private PaymentBuilder paymentBuilder;
    private MainframePaymentMessageBuilder mainframeMessageBuilder;
    private MainframePaymentsService mainframePaymentsService;

    public PaymentService(
            PaymentBuilder paymentBuilder,
            MainframePaymentMessageBuilder mainframeMessageBuilder,
            PaymentRepository paymentRepository,
            MainframePaymentsService mainframePaymentsService) {

        this.paymentBuilder = paymentBuilder;
        this.mainframeMessageBuilder = mainframeMessageBuilder;

        this.paymentRepository = paymentRepository;
        this.mainframePaymentsService = mainframePaymentsService;

    }

    public void makePayment(PaymentDocument document) {

        Payment payment = paymentBuilder.buildPaymentFrom(document);
        PaymentMessage paymentMessage = mainframeMessageBuilder.buildPaymentMessage(payment);

        mainframePaymentsService.makePayment(paymentMessage);
        paymentRepository.save(payment);

    }
}

In this instance (which is a _simplified_ real-world example- and please ignore all the irrelevant bad things in the design of this class) there’s absolutely no need to inject the builders. The repository and the other service, yes, but not the builders.

It’s so, SO easy to forget that what you’re injecting is a domain object (see: FooBuilder example in my comment above). I for one have had to stop myself a couple of times automatically adding another constructor argument for something that should only ever have one implementation anywhere in the system. The smell here is seeing what should be domain objects with a single implementation popping up in your IoC container config.

> I think the post is a little bit extreme.

The title of the post is extreme, this: “What I’m saying is: Use IoC when you need it and use it for what it’s for.” is probably more like it.

If he were alive today we may have seen him do some interesting things with other instruments. I certainly bet he would not like to discover he had been constrained such that he could only ever play one instrument.

It is kind of like the hammer thing. If you get told that every problem in the world must be solved with a hammer then you are less likely to think about that screwdriver in the corner.

Javalobby: (Is IoC / Dependency Injection Overated?) http://www.javalobby.org/java/forums/t78371.html

I have a question about your entry:

1) Do you really think that people advocate “thou shalt use an IoC container EVERYWHERE?” Even if some do, I would suspect that the majority of pro-IoC container developers don’t think that it’s useful EVERYWHERE.

2) What kind of container do you recommend for large projects? J2EE containers came about because of a need for containers in LARGE project. Heck, even Tiles has a container… You need some method of managing dependencies.

3) Your example is a Domain object. IoC’s generally help manage configuration of the view, service and persistence layers, where interfaces and configuration are much more important. IoC/AOP in the Domain layer is most definitely a controversial. What exactly was your intention by using a domain-type argument? Was it to prove that IoC is overrated or that IoC is not applicable for THAT particular case?

I personally like what IoC and IoC Containers can do for me. They do pay the bills right now. However, I’m always on the lookout for other advancements in technology theory and practical use. I’m also looking for clearly stated “best practices” types of advice and discussions as to when to use something and when not to use something. IMHO, IoC Container (and specifically Spring Framework) “best practices” are still emerging even after almost three years of IoC being in the lime-light.

With that said, thanks for the post. It definitely brought about some interesting discussions.

I dislike the example above because the dependency injected looks more like state based DI instead of role based DI.

One tangible benefit I have seen using DI properly is that I can move aspects from one implementing class to another, and I don’t break any consumers. In the above example, if I moved the role that the Guitar actually played to another class, I would be forced to change the Rock class (blech!).

(and George, please correct me if I’m misrepresenting you)

1. Nobody’s advocating using this technique anywhere other than in unit tests.
2. Nobody’s suggesting there isn’t a place for IoC containers, just that wiring up everything and its dog in Spring IoC is often overkill.

What George is talking about is things a bit like this:

class Jimi {
private Instrument instrument;

public Jimi(Instrument instrument) {
this.instrument = instrument;
}
}

We all know Jimi’s always going to play guitar. If Jimi’s not playing guitar, that’s not really what we wanted. So why bother exposing it? Why not just say:

class Jimi {
private Instrument instrument = new Geetar();

public Jimi() {
}
}

We’ve expressed the intent that Jimi should ALWAYS play guitar. We’ve avoided some more unnecessary configuration in our IoC container.

This is all to the good, shurely?

A better, real-world example would be a service that uses a builder to create one object from another (a Foo from a Bar). It’s a reasonable expectation that there will only ever be one way you can make a Foo from a Bar in your system. So why bother injecting the builder into your service? Why bother even suggesting there will ever be another type of builder in your container configuration?

What I like about George’s post is that he’s challenging all those well-ingrained architectural decisions we make (thou shalt use an IoC container EVERYWHERE) and pointing out that actually, a lot of the time, we make more work for ourselves like this.

Sometimes this is a bad idea on the basis that it’s better to have a consistent architecture that leads to over-engineering in some places. On the project we’ve just come off, I don’t think that was the case and this technique worked well for us.

I normally encourage the use of IoC between layers, so that the view layer does not access the logic layer directly etc. IoC within layers is normally overkill.