by Eric

Assistedinject is cool. But there are chances that we don’t want so many interfaces when our code is simple and not likely to change. Here is a version do the same thing as assistedinject while without any interfaces and binding configuration:

I use to think that the “new” is the enemy of Guice, and should be totally eleminated. Truely, the “new” breaks the chain of Guice object graph, but can we create a ‘perfect’ world without “new”? No. The Guice is perfect in creating object graph upfront, but it can’t predict the dependencies in the runtime. In fact, altimately, the “new” is still the only option in such situation. Then, how could we get out of the delima? It is actually simple: let Guice do what it is good for, and so to “new”.

Guice provide “Provider” interface to support the refactoring of the existing factory methods, like this:

publicclass GumProducer implements Provider<Gum>{

@Override

public Gum get() {

returnnew Gum();

}

}

But sometime the Gum is not that simple, what if it has its own dependencies, like GumPack? GumProducer is nothing special to Guice except the get() method, so just treat it as a common class and leave the dependencies to Guice: