I'm going to be using C# for this article, but the principle is what is important. Focus on the principle behind the code. :)

Imagine you get an email one morning, Valve Software wants you to prototype their next MUD game. It's going to be a dungeon crawler RPG where you will have warriors, weapons, spells, the works.

"Ok, you think to yourself. I can do this! :)"

"Great! First I need you to create our Warrior class and give him a sword just to start out."

So, you create a Warrior class:

public class Warrior
{
    Sword sword;

    public Warrior()
    {
        sword = new Sword();
    }

    public void Attack(string target)
    {
        sword.Hit(target);
    }
}

Then you create the Sword class:

public class Sword
{
    public void Hit(string target)
    {
        Console.WriteLine("You slice {0} in half!", target);
    }
}

Finally, this is how you would use it:

static void Main(string[] args)
{
    Warrior gustaf = new Warrior();
    gustaf.Attack("Orc");

    Console.Read();
}

And as expected, it works. "Send my check in the mail", you think. But hold on! Valve calls you the following morning and tells you that the producer wants another weapon for the warrior. They want to give the warrior an axe.

"No problem, Mr. Business Man Guy - I'll get right on that.", you say.

Let's create another class for the Axe then:

public class Axe
{
    public void Hit(string target)
    {
        Console.WriteLine("You smash the puny {0} with your mighty axe!", target);
    }
}

How can we tell our Warrior to use this...hm. Let's try this:

public class Warrior
{
    Sword sword;
    Axe axe;

    public Warrior()
    {
        sword = new Sword();
        axe = new Axe();
    }

    public void Attack(string target)
    {
        sword.Hit(target);
    }
}

But wait - how do we know what weapon the warrior is supposed to use? :(

What about this, we can use a boolean attribute and use that to decide whether we use the sword or the axe.

public class Warrior
{
    Sword sword;
    Axe axe;
    private bool _useSword;

    public Warrior(bool useSword)
    {
        sword = new Sword();
        axe = new Axe();
        _useSword = useSword;
    }

    public void Attack(string target)
    {
        if (_useSword)
            sword.Hit(target);
        else
            axe.Hit(target);
    }
}

So far so good, you can practically smell the check in the mail. You commit the code to your repository and you get an email 20 minutes later from the Bossman.

"Are you sure you thought this through? What are you going to do when we decide the warrior will have another weapon and another and another?"

When you coded as we just did above, you acquire a lot of technical debt. Stuff you're going to be held accountable for in the future and you will have to face it.

Let's use Dependency Injection to improve this code and make sure Valve pays us.

First, lets create an interface called IWeapon. This will have a single method, Hit.

public interface IWeapon
{
    void Hit(string target);
}

Now let's modify our Sword and Axe class:

public class Sword : IWeapon
{
    public void Hit(string target)
    {
        Console.WriteLine("You slice {0} in half!", target);
    }
}

public class Axe : IWeapon
{
    public void Hit(string target)
    {
        Console.WriteLine("You smash the puny {0} with your mighty axe!", target);
    }
}

Great, our two weapons are implementing the IWeapon interface.

Lets modify the Warrior class to take advantage of this chage:

public class Warrior
{
    private IWeapon _weapon;

    public Warrior(IWeapon weapon)
    {
        _weapon = weapon;
    }

    public void Attack(string target)
    {
        _weapon.Hit(target);
    }
}

Notice how cleaner the code is and how easily we can inject the dependency. Here's how we would use this:

static void Main(string[] args)
{
    Warrior gustaf = new Warrior(new Axe());
    gustaf.Attack("Orc");

    Console.Read();
}

Since we are using interfaces instead of concrete objects, we no longer need specific object types in our class. In the constructor of the Warrior class, we can inject whatever concrete implementation we need.

"Sergio, what in the hell does all this mean? I'm still waiting for the punchline."

The benefit of Dependency Injection being able to expand an existing system without the need for modification on our part. Since we use interfaces, implementation details are not necessary so long as they follow the interfaces contract.

In the next article, I'll look into Ninject and how to use this to automatically inject dependencies without the need to wire things up manually.