In the past I have worked with several different tools that allow for Dependency Injection for .NET such as Spring.NET, Castle Windsor, Ninject, and of course Microsoft’s own Unity. It seems like every time a .NET developer gets bored, their pet project ends up being the creation of a new IoC container.

At its core, Dependency Injection is a pattern where developers write code against interfaces and then specific implementations of those interfaces are injected at runtime either by file-based configuration, code-based configuration, or some combination of convention and configuration.

For example, I might have written my application to use a repository called SmurfRepository, which I then use to store and retrieve smurfs. If this was a .NET application then I might have written all of my code to work against an interface called ISmurfRepository. I then allow the Inversion of Control container to inject an implementation of ISmurfRepository at runtime. This lets me do things like run against an in-memory smurf repository while I’m in testing mode and a SQL-backed Smurf repository when running in production mode.

Google wouldn’t be Google if they didn’t have their own library that did something that’s already been done before, so they have Guice. The value proposition for Guice is the same as it is with many Google libraries – it’s just brain-dead simple to use. If you’ve ever used Spring or Spring.NET then you know what bloated, clunky, convoluted dependency injection looks like. Guice is the anti-Spring, and that’s a good thing.

So let’s see what Guice looks like in action. First, we need to create our application code that works against interfaces so let’s create a class called ChessPiece:

public class ChessPiece {
    private GameBoard _gameBoard;

    @Inject
    public ChessPiece(GameBoard gameBoard) {
        _gameBoard = gameBoard;
    }

    // real implementation goes here.
}

This pattern should look fairly familiar to developers who have used DI before. The chess piece needs a reference to the game board on which it sits and it gets that reference at construction time. The interesting bit here is the @Inject attribute (I’m using the Guice version, not the javax version, since the Guice one is a bit more flexible). This annotation tells Guice that it can invoke this constructor with an injected implementation when some object requests and instance of this class. In the above code, GameBoard is an interface (e.g. you’d call it IGameBoard in .NET).

We might have multiple different classes that implement GameBoard such as one for unit testing, another for integration testing, and maybe one for production. We could also have the game boards differ in terms of creating a local game board (all players are in-process) or a networked game board (player 1 is local and player 2 is communicating with the game board via network messages). The purpose of this pattern is that it shouldn’t matter to consumers of the GameBoard interface which implementation has been injected at runtime.

To get an instance of the ChessPiece class, we just ask the injector for it:

MultiplayerModule module = new MultiplayerModule();
Injector injector = Guice.createInjector(module);
ChessPiece piece = injector.getInstance(ChessPiece.class);

Once you get a real object instance in the piece variable, Guice will have already located, instantiated, and supplied a concrete implementation of GameBoard and given it to the chess piece’s constructor. The bindings that tell Guice which implementation to use for a given interface can be done via Guice modules, like this one for a multiplayer environment:

public class MultiplayerModule extends AbstractModule {
    @Override
    public void configure() {
        bind(GameBoard.class).to(TCPNetworkMultiplayerGameBoard.class);
    }
}

I really like the way modules allow us to group a bunch of bindings together into a logical unit and that logical unit is a piece of code rather than a 5 bajillion line XML file. The code you see here (aside from the imports that I’ve snipped out) is all you need. There are no configuration files, no massive setup times, no rigging, just write your code against interfaces, mark your constructors, setters, and methods as injectable, and Bob’s your uncle.

As you can see, if there is one Dependency Injection library that exemplifies Kotan (elegant simplicity), then Guice is it.