This sounds like a good idea but wont to get a "Already bound" exception ?
Den mandag den 10. marts 2014 20.26.26 UTC+1 skrev Nate Bauernfeind:
>
> 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.
