That makes a lot of sense, thanks. I'm not sure it will solve all
scenarios..but lets see.
Den mandag den 10. marts 2014 21.27.38 UTC+1 skrev Nate Bauernfeind:
>
> 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()
>
> And the magic just happens. It doesn't matter if Thing1/Thing2 are in the
> same module or separate modules as long as the ThingService exists
> somewhere and are being created as part of the same injector. And note that
> the private classifier allows you to hide the fact that Guice is going to
> do this for you. So you never have to worry about users of Thing1/Thing2
> abusing that method (at-least I like making it private; your milage may
> vary =P).
>
> If you bind AbstractThing to Thing1 and to Thing2 you will get an already
> bound exception. But the AbstractThing class doesn't need to show up in any
> bindings for the injection to occur.
>
> Good luck,
> Nate
>
> On Mon, Mar 10, 2014 at 3:15 PM, Mikkel Petersen
> <[email protected]<javascript:>
> > wrote:
>
>> 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] <javascript:>.
>> To post to this group, send email to [email protected]<javascript:>
>> .
>> 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.
