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 dirk.ol...@googlemail.comwrote:
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 google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@googlegroups.com.
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 google-guice+unsubscr...@googlegroups.com.
To post to this group, send email to google-guice@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.
