Well the predictors are being handed to the dispatcher like this:
@Inject
public int registerPredictors( PredictorProfileList predictors )
{
if( _predictors == null )
_predictors = predictors;
else
_predictors.addAll( predictors );
return predictors.size();
}
Currently the Dispatcher has no non-default constructors.
Can't I pass in a Provider like this:
@Inject
public Dispatcher( Provider<DispatchHandler> handlerProvider )
{
_handlerProvider = handlerProvider;
}
and have the dispatch method call it a bit like this:
public boolean dispatch()
{
for( PredictorProfile predictor : _predictors )
{
DispatchHandler handler = _handlerProvider.get();
handler.handle( _predictor );
}
return true;
}
?
Granted that would disguise the fact that DispatchHandlers are Threads
but is that necessarily a bad thing? Or is there another reason to
avoid doing it this way?
Thanks for all the feedback -- much appreciated...
Andrew.
2008/10/16 Bob Lee <[EMAIL PROTECTED]>:
> Providers work when everything is injected, but in this case, you have a run
> time argument. Mixing injected dependencies with run time arguments in a
> statically typed-fashion requires you to roll your own factory/builder.
>
> You could just add a predictor setter to DispatchHandler and then just
> inject a Provider<DispatchHandler> into Dispatcher, but I prefer things to
> be immutable myself.
>
> Bob
>
> On Thu, Oct 16, 2008 at 9:24 AM, Andrew Clegg <[EMAIL PROTECTED]>
> wrote:
>>
>> Okay... You took me by surprise a bit, I was expecting something based
>> on Provider<DispatchHandler>. Like injecting a
>> Provider<DispatchHandler> as one of the arguments to the Dispatcher
>> constructor (or a setter).
>>
>> Have I got the wrong end of the stick? Is that not what Providers are
>> meant for?
>>
>> Thanks,
>>
>> Andrew.
>>
>> 2008/10/16 Bob Lee <[EMAIL PROTECTED]>:
>> > Oh, Jesse also has AssistedInject which can help with this stuff, but I
>> > still like to kick it old school. He can tell you more.
>> >
>> > Bob
>> >
>> > On Thu, Oct 16, 2008 at 9:16 AM, Bob Lee <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Assuming you need to inject stuff into DispatchHandler and you don't
>> >> want
>> >> Dispatcher to know about DispatchHandler's deps, here's how I would do
>> >> it.
>> >>
>> >> public class Dispatcher {
>> >>
>> >> private final DispatchHandler.Factory handlerFactory;
>> >>
>> >> // package-private for unit testing
>> >> @Inject Dispatcher(DispatchHandler.Factory handlerFactory) {
>> >> this.handlerFactory = handlerFactory;
>> >> }
>> >>
>> >> ...
>> >>
>> >> public boolean dispatch() {
>> >> for(PredictorProfile predictor : predictors) {
>> >> handlerFactory.newInstance(predictor).start();
>> >> }
>> >> return true;
>> >> }
>> >> }
>> >>
>> >> public class DispatchHandler extends Thread {
>> >>
>> >> private DispatchHandler(PredictorProfile predictor, Dep1 d1, ...) {
>> >> ...
>> >> }
>> >>
>> >> ...
>> >>
>> >> public static class Factory {
>> >>
>> >> private final Dep1 d1;
>> >> ...
>> >>
>> >> // package-private so we can unit test easily.
>> >> @Inject Factory(Dep1 d1, ...) { ... }
>> >>
>> >> ...
>> >>
>> >> public DispatchHandler newInstance(PredictorProfile predictor) {
>> >> return new DispatchHandler(predictor, d1, ...);
>> >> }
>> >> }
>> >> }
>> >>
>> >> You could also use "Builder" instead of "Factory" depending on how you
>> >> structure things. Needing this additional class is unfortunate but
>> >> necessary
>> >> unless we extend the language to better support this stuff.
>> >>
>> >> Bob
>> >>
>> >> On Thu, Oct 16, 2008 at 9:02 AM, Andrew Clegg <[EMAIL PROTECTED]>
>> >> wrote:
>> >>>
>> >>> Hey folks,
>> >>>
>> >>> I'm just getting started with Guice (and DI in general). I have a
>> >>> question, hope it's not too dense.
>> >>>
>> >>> I have a method that looks something like this in its first
>> >>> incarnation (_predictors is a collection):
>> >>>
>> >>> public boolean dispatch()
>> >>> {
>> >>> for( PredictorProfile predictor : _predictors )
>> >>> {
>> >>> Thread handler = new DispatchHandler( predictor );
>> >>> handler.run();
>> >>> }
>> >>> return true;
>> >>> }
>> >>>
>> >>> i.e. for each predictor that the object knows about, kick off a thread
>> >>> to process it, and then return. (The return true is just a placeholder
>> >>> for a proper status code later.)
>> >>>
>> >>> Now I've started to think Guicily, I don't like the look of that call
>> >>> to new. Everything else in this app so far is injected for me by
>> >>> Guice.
>> >>>
>> >>> What's the best pattern for this kind of situation?
>> >>>
>> >>> Thanks!
>> >>>
>> >>> Andrew.
>> >>>
>> >>>
>> >>
>> >
>> >
>> > >
>> >
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To post to this group, send email to google-guice@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---
