> On 03/10/2014 09:27 PM, Nate Bauernfeind wrote:
> > No actually you don't get already bound exceptions. Guice actually
> > treats the injection as a setter based injection (it doesn't care how
> > you name methods; but I tend to use the word register since it
> seems to
> > suggest not saving the object).
> >
> > So if you're thinking on the Abstract case you'd have something
> like this:
> >
> > abstract class AbstractThing {
> > @Inject
> > private void registerThing(ThingService service) {
> > service.registerThing(this) }
> > }
> >
> > class Thing1 extends AbstractThing {
> > ...
> > }
> >
> > class Thing2 extends AbstractThing {
> > ...
> > }
> >
> > and in your configure method you can just do:
> >
> > bind(Thing1.class).asEagerSingleton()
> > bind(Thing2.class).asEagerSingleton()
>
> Great trick. But now you're left with pointless Thing1 and Thing2
> instances in the Injector. For only 2 instances that's not worth the
> hassle but in my case they may become hundreds ...
>
> Interesting! Have you found a significant performance overhead? I tend
> to hide bindings like these in a private module, but I doubt that would
> make their cost any cheaper. Can you explain what the cons are from this
> approach? I do things like this all the time now.
Before adopting an approach that you describe I try to think about the
"cost" of it. In your case that's additional instances bound to the
injector and retained throughout the entire lifetime of the Injector. Im
my case that's as long as the app lives.
Now an object here and there and a few extra bindings might be worth the
decoupling you gain from this approach.
-dirk
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.
