How to use Guice for an effective API Design?

Question

I am creating a base API in JavaSE, which includes modules like MVP architecture, Service & Repository Layer, Event Model to fire events between presenter etc.

I am trying to implement all best practices of Software Design. Recently, I read about Dependency Injection & its advantages and decided to use Guice as DI framework.

After spending two days learning Guice, I am still confused with some design issues.

1. If I create an injector using Guice.createInjector(modules) with the core modules of my API,

   • How to make this injector instance available to my other API classes? Can an injector be injected and is it a good practice?
   • How to make this injector instance available to API user, so that they can use this injector to create instances?
   • Should I even make it available to API user, as it may be a bad practice?
   • Hence using it for AOP approach like this and custom injections

2. Is creating injectors a heavyweight operation, if so should there be only a few injectors per application?

3. Should injectors be created on startup stage of the application or could be created in between without affecting the application performance?

---

Edit

To understand usage of Provider instead of injecting injector here is an short MVP example:

interface ProductModel {

  // Some method declarations

}

interface ProductView {

  // Some method declarations

}

class ProductPresenter {

  // Using Guice for constructor injection
  @Inject
  ProductPresenter(ProductModel model, ProductView view) {
    this.model = model;
    this.view = view;
  }

}

class ProductViewImpl implements ProductView {

  // Method Implementations

}

class ProductModelImpl implements ProductModel {

  // Method Implementations

}

Now, as understood from below answers to use Provider<X> instead of injecting injector, here is the Provider class.

class ProductPresenterProvider implements Provider<ProductPresenter> {

  ProductPresenter get() {
    // But, How to provide the ProductPresenter without model and view instances!
  }

}

Answer 1

Ok, those are many questions you have and I guess some of the points can be approached in more than one way.

Creating the injector is not cheap. Guice will do some analysis to detect errors as well as create all singletons. So you should create the injector at startup.

I usually have a single injector for my application.

Regarding your question 1.:

Yes the injector can be injected. But I see it as a bad practice. Reason for this is that calls to injector.getInstance() and injector.injectMembers() make it hard to reason about the dependencies of a class.

• if you need to create more than one instance or you need to control the time when an instance is created inject a Provider instead of X.
• if the object you want to create needs both runtime parameters and dependencies use assisted inject.
• for many kinds of objects (like DTO, POJO and alike) its absolutely ok to create them by calling new or a conventional factory.

In this sense the injector is implicitly available to any instance created by Guice this includes the API user.

And finally AOP. Aspects are a powerful feature but also can hide some of the business logic I suggest to use them only for very repetitive tasks which all developers know well.

Also take into account that aspects only work on:

• instances created by Guice
• non private, non static, non private methods

Finally, Guice won't inform you if you add an annotation to either of the above. Your aspect will silently be ignored

Answer 2

It's a bad practice to inject an injector, or otherwise pass it round in some way that makes it accessible to code outside of startup. That confuses what's going on; do that and when something goes wrong, you have to debug your code via debugging the dependency injection state.

The right, static, way to do things is to inject either a hand-written factory object, or a Provider. The difference being that the latter will set the created object up as a DI object, i.e. processing @Inject annotations.

Internally, the implementation of a provider presumably uses the injector, but as it is only doing it for a single thing it is easier to reason about and debug. And if you draw the dependency graph for your system, because Provider is Provider<X>, you should get the actual graph of logical dependencies with your class depending on X. Not a mess with a 'magic happens' node at a single injector used for everything.

Note that when you do this, you don't need to supply a binding or implementation for the Provider; it has built-in default.

Answer 3

I will give a second answer, but you really should have opened a second question...

First of all: you rarely ever implement a provider. Guice will automagically create them for you. To explain this: When I bind a class Foo as follows:

bind(Foo.class).to(FooImpl.class)

You can inject in you class either Foo or Provider<Foo>. Guice will create the provider for you.

The reason why you should not implement the provider yourself, is that AOP is not working on instances that where created with a call to new. When you use a debugger to look at the run time instance of an injected object which uses interceptors you will notice that Guice created a subclass on the fly allowing it to intercept the method calls.

To your example:

The main problem is, that ProductModel should not be injected. It is a domain object and holds data. These kind of objects should not be created/managed by DI. Instead you code is responsible to create/retrieve and store the model from its persistent state. The presenter has now two different dependencies. One is the model which lives outside of DI and one is the view which can be handled by DI (just as a side note: if you need the same instance of the view to be injected on more than one object you must place it in a (custom-) scope. But answers to scopes deserve a new question).

To solve the above dilemma Guice offers assisted injection. This allows you to write a code like to following:

public class ProductPresenter {

    public interface Factory {
        createPresenter(ProductModel model);
    }

    @Inject
    ProductPresenter(@Assisted ProductModel model, ProductView view) {
        this.model = model;
        this.view = view;
    }
}

you then bind the factory as follows:

install(new FactoryModuleBuilder().build(ProductPresenter.Factory.class));

Guice will create an implementation of the ProductPresenter.Factory interface on the fly. The created instance will get the arguments passed to the factory method put into the constructor. Also AOP is working on the created instance. This way you can mix DI with non DI objects.