Just finished reading through the stack overflow link; thanks for sharing
it. It reminded me of the following:
I've heard/read/adopted the policy that guice modules should sincerely
avoid any conditional logic. If you do find yourself with some conditional
logic try and split your module up by either moving the conditional logic
into a provider or up into multiple modules and let your application choose
which module(s) based on the appropriate mode(s). It's hard to do, and I
probably don't have one project that is conditional free in all configure
methods... but that certainly helps defer the need to inject some things
into a guice module.
Next, I wanted to point out one pattern I've used quite often when it comes
to registering objects for some purpose (like listening to events, or even
to enable key-based delegation to that object). Typically you'll have a
main service you want to register to listen/subscribe on, which I'll use
the example of a DaoService. Users of the DaoService can subscribe to the
Dao to listen for events that occur on any sub-class of a type. So some
handwaving:
class DaoService {
public synchronized void addListener(Class<T> type, DaoListener<T>
listener) {...}
}
public interface DaoListener<T> {
public void dataAdded(T data) throws Exception;
public void dataUpdated(T oldData, T newData) throws Exception;
public void dataRemoved(T data) throws Exception;
}
And then in my user class (and sometimes this is an abstract base class) I
use setter injection specifically to register the listener:
class ExampleUser {
private Listener _listener = new Listener();
@Inject
public ExampleUser(...) {...}
@Inject
private void registerAsDaoListener(DaoService service) {
service.addListener(MyDataType.class, _listener);
}
private final class Listener implements DaoListener<MyDataType> {
...
}
}
So, again, in this example I'm decoupling the idea of who is listening to
what data. Obviously the sender / daoService needs to be around (unlike in
the event bus example), but now no one ever needs to know about how many
listeners there are (depending on how you store your listeners you may need
to make sure you're not overwriting any other listener in the addListener
method).
And.. I also use Scala as often as I can, so sometimes pieces of these end
up in a trait that is easy to mix-in for the repeated functionality (like
managing the listener map/list).
So.. maybe this would be a good alternative to the multibinding extension
for you. I've used it with great success (esp. when the register method is
on an abstract base class).
Good luck and happy Guicing =),
Nate
--
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.
