> On Fri, Sep 10, 2010 at 4:34 PM, Brian Pontarelli <[email protected]>
> wrote:
> I definitely see that the binding is to the interface but what it is doing
> under the hoods is creating only a single instance of MyImpl. Plus, if you
> look at it from the OO perspective, the interface isn't really a singleton
> since it is merely an interface. The singleton is the implementation....
>
> Plus, it seems as though if I create two bindings, one for the interface and
> one for the impl, I'll end up with two instances as singletons.
>
> I could put the @Singleton on the impl and that might work, but I'm not sure
> on that and would need to try it.
>
> I guess it really seems like Guice should handle this automatically for me
> since it is managing the constraint on MyImpl through MyInterface.
>
> The statement "bind(X.class).to(Y.class).in(Scopes.SINGLETON);" is telling
> Guice that you want a single instance when you request "X", not when you
> request "Y". It could be possible that someone wants Z also bound to Y and
> wants that in a different scope, or wants Y itself in a different scope.
Probably not Y in a different scope since it is the Singleton and X is not the
Singleton.
> Or, probably the more common example: if the binding statement was made with
> annotations...
> bind(X.class).annotatedWith(named("foo")).to(Y.class).asEagerSingleton() and
> also
> bind(X.class).annotatedWith(named("bar")).to(Y.class).asEagerSingleton().
> You're telling Guice that you want a single X when you inject it with
> @Named("foo") and another single one when you inject it with @Named("bar").
I guess this is possible, but Y by definition is more than likely a Singleton
instance across the VM. However, I could see the case where you want two
Singleton instances in the VM and to use them differently. Just an odd case I
guess. However, if Guice created only a single Y (as I thought it did), then
this case would be impossible to do with Guice.
>
> If you also added a bind(Y.class).asEagerSingleton(), then when you link from
> X to Y (through your original binding statement), you'll still retrieve the
> sole instance of "Y", since X is really a "linked binding" that just forwards
> its requests to Y. (X still scopes the result as a singleton if you bound it
> that way, and continues to return that scoped instance, but the instance will
> be the same as the one Y created.)
I see this and it does make sense. As long as the linking works as you
mentioned then it would cover my case nicely. In fact, I would expect most
Singletons would want to be linked like this. Therefore, it sounds like Guice
looks for existing instances of a class during injection of a binding. I could
probably do this and it would work:
bind(MyImpl.class).asEagerSingleton();
bind(MyInterface.class).to(MyImpl.class);
-bp
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en.
