Henrique, Yes, that redesign seems like a good solution.
As an improvement, it might be possible to adhere to ( http://code.google.com/p/google-guice/wiki/InjectOnlyDirectDependencies) by injecting Part directly into Machine. That is, I don't know if Machine has any other use for Config and PartFactory to except to create an instance of Part, but if it does not, then the class could be simplified by giving it its instance of Part directly: ClassX { @Inject ClassX( ConfigFactory configFactory, PartFactory partFactory, MachineFactory machineFactory) { .... } void doStuff() { Source source = .... Config config = configFactory.create(source); Part part = partFactory.create(config); Machine machine = machineFactory.create(part); } } with this we because the factories that are injected into ClassX are used simply to pass along (for all intents and purposes) and instance of Source. if your domain is such that it makes sense to define a Machine as creationally dependent on a Source, then you can push the code that transforms Source => Config => Part into MachineFactory: ClassX { @Inject ClassX( MachineFactory machineFactory) { .... } void doStuff() { Source source = .... Machine machine = machineFactory.create(source); } } In this model, ClassX deals direclty with Machine and doesn't know about Part or Config. In reality, ClassX might need those other classes. I'm not sure what your domain looks like. I present this alternative to present another option, mainly for illustration. The best option might be somewhere in between. regards -Fred On Sat, Feb 20, 2010 at 8:46 PM, Henrique Prange <[email protected]> wrote: > Hi Fred, > > First, thanks for your help. > > > On 20/02/10 02:13, Fred wrote: > >> Henrique, >> >> Something knows about Source, which can create a Config. >> >> Something needs a Machine. >> >> What knows about Source and can create a Config? >> >> > There is another class (lets call it ClassX) in Module B that knows about > Source and Config. Also, Machine objects are injected in this class. > > > A Machine is transitively dependent on this creation action, and so it >> necessarily must be downstream of the creation of Source. >> >> What expects a Machine, or more generally, what is the creation >> lifecycle of Machine? >> >> > The ClassX from Module B creates, uses and discards Machine objects. > > I've thought about a change in Module A while trying to answer your > questions. :) > > > Module A > -------- > > public class Machine { > @Inject @Assisted Config config; > @Inject PartFactory factory; > } > > interface MachineFactory { > create(Config config); > } > > class Part { > @Inject @Assisted Config config; > } > > interface PartFactory { > create(Config config); > } > > interface Config { } > > There is a factory now to create Machine objects. The factory accepts an > Config object as parameter. ClassX now can create the Config object using > the ConfigFactory and the Machine using the MachineFactory. > > Is this a good solution? > > Cheers, > > Henrique > > > -Fred >> >> On Feb 19, 5:17 pm, Henrique Prange<[email protected]> wrote: >> >>> Hi all, >>> >>> I'm facing a problem trying to use the injection mechanism between two >>> modules. >>> >>> I have a Module A with the following classes: >>> >>> Module A >>> -------- >>> >>> public class Machine { >>> @Inject Part part; >>> >>> } >>> >>> class Part { >>> @Inject Config config; >>> >>> } >>> >>> interface Config { } >>> >>> Part is not public and is a requirement to build Machines. Part has a >>> dependency on Config. But the Config implementation is not defined in >>> Module A. >>> >>> I have another Module B depending on Module A with the following classes: >>> >>> Module B >>> -------- >>> >>> public class ConfigImpl implements Config { >>> @Inject @Assisted Source source; >>> >>> } >>> >>> interface Source { } >>> >>> interface ConfigFactory { >>> create(Source source); >>> >>> } >>> >>> The ConfigImpl class requires a Source object to be instantiated. The >>> ConfigFactory must be used for this job, but the Machine class doesn't >>> know about the ConfigFactory interface. Also, doesn't make sense to >>> include the Source and ConfigFactory interfaces in Module A. >>> >>> How could I solve this DI problem? I'm sure I have to rethink the design >>> of those classes. So, I would appreciate if you could provide any >>> directions. >>> >>> Cheers, >>> >>> Henrique >>> >> >> > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-guice%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. 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.
