On 13 Apr 2010, at 16:34, Vladimir Blagojevic wrote: > Hi, > > Shouldn't we strive to minimize the number of fields in composite components that we create. I am working with StateTransferManagerImpl, DistributionManagerImpl and they both have so many fields it is overwhelming :) > > Why don't we inject AdvancedCache instead and then get references through it? We could, but then AdvancedCache becomes a registry of sorts. And also makes it harder to unit test (as you will then *always* need an AdvancedCache stub).

Cheers -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 14 Apr 2010, at 10:10, Galder Zamarreno wrote: > > ----- "Manik Surtani" <manik(a)jboss.org&gt; wrote: > >> On 13 Apr 2010, at 16:34, Vladimir Blagojevic wrote: >> >>> Hi, >>> >>> Shouldn't we strive to minimize the number of fields in composite >> components that we create. I am working with StateTransferManagerImpl, >> DistributionManagerImpl and they both have so many fields it is >> overwhelming :) >>> >>> Why don't we inject AdvancedCache instead and then get references >> through it? >> >> We could, but then AdvancedCache becomes a registry of sorts. And >> also makes it harder to unit test (as you will then *always* need an >> AdvancedCache stub). > > If you want to reduce the number of parameters, you could simply inject (Global)ComponentRegistry, which are the actual registries and retrieve the necessary components from there. That's even worse. You lose all of the lifecycle management of components, including start and stop ordering and lazy construction, if you hack around the component injection fwk this way. :)

> If some of those parameters are only used once, it might make sense to do this. Otherwise, if they're used multiple times, you might as well inject the parameter directly. > >> >> Cheers >> -- >> Manik Surtani >> manik(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev