Why to use a IoC framework

Question

I've been reading about Inversion of Control frameworks and I'm just playing around with the question: "Why in the hell do I need a framework to do this?"

Don't misunderstood my question... the pattern is something we programmers use often but... a full featured framework to do that?

I must be missing something and that's the reason I'm posting the question. I've seen a lot of examples on the web and I just don't get it. mi mind is blocked to the idea maybe.

Just take a look at the Ninject Home page's example:

public class Samurai {
    public IWeapon Weapon { get; private set; }
    public Samurai(IWeapon weapon) {
        Weapon = weapon;
    }
}

public class WarriorModule : NinjectModule {
    public override void Load() {
        Bind< IWeapon >.To< Sword >();
    }
}

The "Samurai" class is ok to me. The "NinjectModule" framework seems unnecessary to me.

I'm assuming later in the code we will be creating new "Samurai" instances passing in "Sword" instances to it, something like:

Samurai theWarrior = new Samurai(WarriorModule.GetInstance(IWeapon));//no coupling

which could be replaced by:

Samurai theWarrior = new Samurai(new Sword());//still no coupling

or

Samurai theWarrior = new Samurai(GetWeaponFromXML());//no coupling yet

What's the part I'm missing? Could you please tell of some scenario where Ioc framework could be needed in my Application?

Thanks.

UPDATE AFTER 4 ANSWERS: I really liked all of the answers I got from you guys. I just read this post dependency-injection-dissection/ where the guy use it for Unit Testing and the StackOverflow link you just provided and Yeah, I was missing the big-big-big complexity part, so let custom myself to use a IoC framework. Thanks again.

I would vote your answers but I just get an orange message saying I can't.

Thanks to the guy who highlighted the code I posted.

Answer 1

This is the problem with code samples. They're either complex and you haven't explained your point, or they're trivial and then seem pointless.

What the WarriorModule is doing is binding a concrete type to an interface, and so whenever another class needs an implementation of that interface, it receives one automatically by the IoC container. The class with the dependency has no dependency on the concrete type, and so has lower coupling and higher testability. I think you knew that already.

In your replacement scenarios, the Samurai class isn't coupled to the sword class, but the calling code still is. You could push that out another level, but that code would now have the dependency, and your intervening class would now have to marshall all the dependencies.

The IoC container does this for all mappings, putting it in only a few places (the module classes). The rest of your code is free not to care, not to have dependencies on concrete types.

Hope that helps.