An overview of Guice

Dependency injection (DI) is a way to give an object it's dependencies. There are a few flavors of this, but first, let's just get on the same page.

A dependency of a class is something it needs to operate. It will encapsulate some amount of functionality whose implementation the dependant class can ignore.

A basic example of this would be a BillingProcessor class might have a dependency on SalesTaxCalculator. It doesn't need to know how this works and the Law of Demeter (aka the priniciple of least knowledge) says that we shouldn't care how it works.

Dependency injection (the means of giving a class it's dependencies) can take two main forms: constructor injection and setter injection. They're pretty much what they sound like. Constructor injection is passing in the dependencies to the constructor. With setter injection, you create the object with an empty constructor and call setFoo to add the Foo dependency.

I personally prefer constructor injection, because you don't have an object which is in an intermediate invalid state which eliminates lots of checking to ensure the object is valid.

You can do DI without Guice, but it eventually gets a bit complicated. For our example, we'll design an event-based notification service.

public interface EventCoordinator {
  public Boolean schedule(Event ev);
}

public interface Emailer {
  public void email(User u, String title, String body);
}

The implementation of this is pretty straight forward.

public EventScheduler implements EventCoordinator {
  private Emailer emailer;

  public EventScheduler() {
    this.emailer = new EmailService();
  }

  public Boolean schedule(Event ev) {
    try {
      for (User u : ev.recipients()) {
        this.emailer.email(u, ev.title, ev.body);
      }
    } catch (Exception exc) {
      return false;
    }
    return true;

  }
}

This suffers from some problems, in that our email service is hard coded, which means when we write our unit tests, we'll be sending real emails to people, which isn't good. Instead of this, we need to sub out the emailer implementation at test time.

public EventScheduler implements EventCoordinator {
  private Emailer emailer;

  public EventScheduler(Emailer em) {
    this.emailer = em;
  }

  public Boolean schedule(Event ev) {
    /* ... */
  }
}

This is solid. This is easily testable by creating a fake implementation of the Emailer. As this code grows beyond toy examples and the dependency graph of your dependencies becomes longer, you end up with code that looks more like a yak shave.

new EventScheduler(
  new RealEmailService(
    new EmailServiceTokenFetcher(username, password),
    new RateLimiter(maxEmailsPerHour),
    new EmailTemplate(new FileLocator("template/dir/path/"),
      new UserPreferenceSelector(new DatabaseConnection(...), ...))
  )
)

This is where Guice comes in. You tell Guice that you want an implementation of Emailer and it goes and figures out all the things it needs to do to make one.

Once setup, Guice is pretty straight forward to use. In each of your constructors that need to have something injected in them, you just add an @Inject annotation and that tells Guice to do it's thing.

public EventScheduler implements EventCoordinator {
  private Emailer emailer;

  @Inject
  public EventScheduler(Emailer em) {
    this.emailer = em;
  }

  public Boolean schedule(Event ev) {
    /* ... */
  }
}

Guice figures out how to give you an Emailer based on the type. If it's a simple object, it'll instantiate it and pass it in. If it has dependencies, it will resolve those dependencies, pass them into it's constructor, then pass the resulting object into your object.

When you want to actually get your instance of EventScheduler, you just need to create an injector and ask for one. This usually lives in your application's main() method. Guice will fill in this object's dependencies and any of its dependencies and so on.

Injector injector = Guice.createInjector(new MyModule()); // modules are the next section
EventScheduler scheduler = injector.getInstance(EventScheduler.class);
scheduler.schedule(...)

But wait.. emailer is an interface, not an instantiatable thing. How does Guice know how to give you one of those?

Guice is configured with one or more "modules". These inherit from AbstractModule.

public class MyModule extends AbstractModule {
  @Override
  protected void configure() {
    bind(Emailer.class).to(RealEmailService.class);
  }
}

You can also tell Guice how to create specific object with don't have @Inject annotations (likely because they're a third party library) by adding methods to your module annotated with @Provides. These methods can also take in arguments which are things Guice knows how to build for you.

public class MyModule extends AbstractModule {
  String TEMPLATE_PATH = '/path/to/templates';

  @Provides
  RateLimiter generateRateLimiter(UserPreferenceSelector prefSel) {
    return new EmailTemplate(new FileLocator(TEMPLATE_PATH), prefSel);
  }

  /* ...configure... */
}

So this all works based on types. What happens if you have multiple versions of the same type? This happens pretty often with configuration variables which are inevitably ~String~s.

Depencency injection makes for really great test seams, where you can pass in your own mocked objects. Beyond that, you may want to test your actual Guice configuration or use your Guice configuration for integration tests.

Spring is a tool which some folks have experience with. It predates Guice by 5 years. It's a primarly XML oriented framework, but it does a lot more than Guice. It does some dependency injection, but also comes with a full MVC web framework.

Guice, while being simpler (by virtue of being focused on a small task and having hindsight), also manages to accomplish more in less code. Because it's just normal Java code, it also has good compiler checking for ensuring your constructors are well formed.

There is support for having both Guice and Spring play nicely together.

Aspect Oriented Programming (AOP) is a mechanism to wrap the functionality of existing code. It's a reasonable fit for things that have cross-cutting concerns, like authorization or metering.

In short, it allows you to intercept the call of a method and do something before it, instead of it, or use the return value of the intercepted method for some purpose. This is similar to defadvice for elisp hackers or python's decorators.

There are other AOP frameworks (AspectJ being the fastest for how it does bytecode weaving) which Guice interoperates with.

If you're curious about this and how it works, check out Guice's documentation on it.