I agree. If these objects weren't meant to exist throughout the life of my application then binding them as singletons is not a good idea. Additionally, you wouldn't want the listener subscription to last forever either. I instead move subscribe and unsubscribe into start and stop methods. In cases like this I have found two options for injection. For most cases I use an AssistedInject factory since I still want guice injections but I'll typically create multiple instances keyed by something (like user or client). On a recent project I actually wanted to create a rich sub-graph of objects per client, so I actually created a childInjector where I had a 'ServiceName' token bound and I was able to remove most of the assisted inject factories. I injected those objects as eager singletons in the childInjector, but without the registerThing injection. Instead I call start and stop on every object in the subgraph as a client was being provisioned and deprovisioned.
So, I guess I don't mind paying for the increased start-up time and the extra map entries if it means I don't have to do any manual dependency management. I also wouldn't call this pattern a decoupled pattern. IMO, this is still quite coupled. The listener has to 1) implement an interface defined by the service (either directly, with a static inner class, or use some arbitrary implementation) and 2) it has to inject the service that it wants to listen to (which the pattern I showed tries to hide). So the listener still has to know enough of the service. A decoupled approach would be the eventbus solution I talked about earlier in the thread; in that case both parties only need to know about the event bus and the message models/types. In this model it doesn't matter who's generating the content or who's consuming the content. Whereas in the case where the service maintains a listener list/mapping then there really can only be one generator. Nate On Wed, Mar 12, 2014 at 1:29 PM, Dirk Olmes <[email protected]>wrote: > > 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. > -- 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.
