Take a look at the AssistedInject extension @ http://code.google.com/p/google-guice/wiki/AssistedInject .
sam On Mon, Apr 11, 2011 at 11:07 AM, David Hoffer <[email protected]> wrote: > Nope, my factories are as plain as they get, i.e. > > public class MyClassFactory implements IMyClassFactory { > > public MyClass createMyClass(String param1, String param2, String > param3, int param4, double param5) { > return new MyClass(param1, param2, param3, param4, param5); > } > } > > The whole purpose of this factory is so I can inject IMyClassFactory into > other classes that need to 'new' MyClass so that class is mock testable. > > I'd love to use Guice so I don't need to write these factories but how do I > pass param1, param2, param3, param4 & param5 into MyClass's constructor? > > -Dave > > > > > On Mon, Apr 11, 2011 at 6:00 PM, Fred Faber <[email protected]> wrote: > >> This is similar to a question from earlier this week... >> >> Guice will help you remove invocations of "new" on service objects. >> >> It won't be a replacement for your domain-level factory objects i.e., >> objects that do more work on an object than simply instantiate it. >> >> Such a factory might look like: >> >> class YourFactory { >> private final Provider<Foo> fooProvider; >> >> @Inject YourFactory(Provider<Foo> fooProvider) { >> ... >> } >> >> Foo createFoo(ArgType1 arg1, ArgType2 arg2, ...) { >> Foo foo = fooProvider.get(); >> ... manipulate foo, probably using the args given above >> } >> } >> >> Note that AssistedInject can remove the boilerplate if all the factory is >> doing is to use the argument it gets as constructor arguments to the thing >> it is creating. But it sounds like your requirements are more in-depth in >> that the Factory seems to be doing more work than simply instantiating an >> object. >> >> Fred >> >> On Mon, Apr 11, 2011 at 10:45 AM, dhoffer <[email protected]> wrote: >> >>> I'm taking a look at Guice to see how it would work for us, currently >>> we code the IoC manually (giant main that wires everything up) and use >>> factories to create dynamic objects so all methods are mock testable, >>> i.e. no 'new' in the code (just in the main and factories). >>> >>> I get how Guice solves the IoC part with @Inject & modules, however >>> how does it help with the factories that generate dynamic objects? >>> I.e. a method that calculates values, creates an object with those >>> values, and does some work on and/or returns the object. How does >>> Guice stop us from needing to write the class factory that generates >>> the object? It looks like I could inject a typed Provider but that >>> doesn't let me create the object with the values just created >>> dynamically. (Also it would tie my code to the Guice APIs.) >>> >>> So it seems Guice solves the static part of the app but not the >>> dynamic part or am I missing something? >>> >>> -- >>> 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. >>> >>> >> > -- > 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. > -- 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.
