To me, Provider should only be used if, in order to create the instance,
you need some additional information that's not available at the very
beginning of the application, when Guice establishes all the bindings. From
this standpoint, @Inject and providers are not really interchangeable:
- @Inject: the instance can be created at startup
- Provider: the instance needs information only available after Guice
has created the module
- Assisted injection: the instance needs a mix of runtime parameters and
injected dependencies
And these days, I'm more and more thinking toward removing Providers
completely and using assisted injections everywhere, even when all the
parameters to the factory are @Assisted since it's quite likely that, as
the code evolves, it will end up needing some injected dependencies, so
since I will end up having to convert these providers into assisted
factories anyway, I might just go ahead and go there directly.
I have settled on a pattern that looks like this:
class Foo {
// Assisted injection
public interface IFactory {
Foo create(Person p);
}
@Inject
private Foo(@Assisted Person p, InjectedResource resource1) {
...
}
}
And whenever I need a Foo:
@Inject
private Foo.IFactory factory;
foo = factory.create(person);
--
Cédric
--
Cédric
On Thu, Apr 11, 2013 at 4:32 AM, Stuart McCulloch <[email protected]> wrote:
> Note that Provider<X> is not guaranteed to always return a new instance,
> it depends on the scope of the binding behind it.
>
> If X has been bound as a singleton in the injector then you'll always get
> the same instance returned from Provider<X>.get().
>
> On 11 Apr 2013, at 09:32, Peter Reilly wrote:
>
> I totally disagree. Provider<X> a, a.get(), is the correct replacement for
> new X();
>
> Peter
>
> On Thu, Apr 11, 2013 at 8:06 AM, Christian Gruber <[email protected]>wrote:
>
>> It is easier, but please don't. While the two are practically similar,
>> it is a design obfuscation to inject a Provider<Foo> merely to serve as a
>> factory of Foo. Provider is an internal type to Guice/DI, whereas a
>> factory is class that manages value types and domain objects.
>>
>> It is technically valid to do this, but it starts to conflate the kinds
>> of objects in your system and can lead to increased mess.
>>
>> Injecting Provider<Foo> is advisable for crossing barriers where you
>> cannot properly scope objects because of limitations of legacy platforms,
>> etc., or to defer construction for optimization. But if you have classes
>> that you need created frequently and you need new instances, consider
>> keeping them as factory managed.
>>
>> I tend to divide my code into Collaborators/Services, Configuration, and
>> Value-Types/consumables. The former I inject, the latter I create with
>> Factories. I admit this is merely an opinion. Stephan is not wrong, but I
>> think it's inadvisable to use Provider<T> as a factory merely because it
>> has a no-args get() method which is similar to create().
>>
>> Christian.
>>
>>
>> On 11 Apr 2013, at 1:27, Stephan Classen wrote:
>>
>> If your factory method has no arguments it is easier to remove the
>>> factory and have guice inject a Provider<MyClass> instead of the factory
>>>
>>> see:
>>> http://code.google.com/p/**google-guice/wiki/**InjectingProviders<http://code.google.com/p/google-guice/wiki/InjectingProviders>
>>>
>>>
>>> On 04/11/2013 04:33 AM, Newbie McBozo wrote:
>>>
>>>> Thanks for your help guys, I figured it out.
>>>>
>>>> The way I attacked this was this:
>>>>
>>>> I created a factory interface. I then added a line to the configure
>>>> function of the module:
>>>>
>>>> binder.install(new FactoryModuleBuilder().build(**
>>>> MyClassFactory.class));
>>>>
>>>> rather than calling "new" for new instances of the class, I inject a
>>>> factory and call MyClassFactory.create().
>>>>
>>>> I'm not explaining it very well, but my code is working. The variables
>>>> that I was trying to inject are now resolving appropriately.
>>>>
>>>> On Wednesday, April 10, 2013 5:09:25 PM UTC-7, Newbie McBozo wrote:
>>>>
>>>> I get that, and forgive me for being dense, but I don't get how to
>>>> make it so that my class is created by Guice so that my injections
>>>> will work.
>>>>
>>>> I see that the application provides a module that's called on
>>>> startup. Within that module I see a series of functions that call
>>>> binder.bind and in all of those classes I see that injection works.
>>>>
>>>> Looking at that, I would think that I could binder.bind my own
>>>> class but that doesn't seem to work. I could have syntax issues,
>>>> but my sense is that there's a fundamental thing that I'm missing.
>>>>
>>>> On Wednesday, April 10, 2013 4:15:28 PM UTC-7, Thomas Broyer wrote:
>>>>
>>>> Dependency Injection 101: only objects created by the DI
>>>> container (Guice in this case) are injected; this means only
>>>> objects that have been retrieved from the Injector (through
>>>> its getInstance method generally) or have themselves been
>>>> injected into other classes. It's possible to inject objects
>>>> that you 'new' yourself (or more generally have not been
>>>> created by Guice itself), but again it has to be explicit:
>>>> https://code.google.com/p/**google-guice/wiki/Injections#**
>>>> On-demand_Injection<https://code.google.com/p/google-guice/wiki/Injections#On-demand_Injection>
>>>> <https://code.google.com/p/**google-guice/wiki/Injections#**
>>>> On-demand_Injection<https://code.google.com/p/google-guice/wiki/Injections#On-demand_Injection>
>>>> >
>>>>
>>>> On Thursday, April 11, 2013 12:21:20 AM UTC+2, Newbie McBozo
>>>> wrote:
>>>>
>>>> I'm working with an application that uses Guice.
>>>>
>>>> I know nothing about guice, and parsing the documentation
>>>> for my particular situation hasn't been easy.
>>>>
>>>> I have a java class. That class needs an object provided
>>>> by the application.
>>>>
>>>> If I subclass an application provided class and override
>>>> it's binding, obtaining the object is a matter of
>>>> @Inject
>>>> AppObject ao
>>>>
>>>> Within my own classes, if I try that, the injected object
>>>> is null.
>>>>
>>>> How do I set up my own classes so that when I instantiate
>>>> them, the injected fields are resolved?
>>>>
>>>> I imagine that I need to bind my class, but I'm having
>>>> difficulty figuring it how to do that without spending
>>>> time learning way more about Guice than this fairly simple
>>>> (and I imagine common) situation really should require.
>>>>
>>>> --
>>>> 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
>>>> google-guice+unsubscribe@**googlegroups.com<google-guice%[email protected]>
>>>> .
>>>> To post to this group, send email to [email protected].
>>>> Visit this group at
>>>> http://groups.google.com/**group/google-guice?hl=en<http://groups.google.com/group/google-guice?hl=en>
>>>> .
>>>> For more options, visit
>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>>>
>>>>
>>>>
>>> --
>>> 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
>>> google-guice+unsubscribe@**googlegroups.com<google-guice%[email protected]>
>>> .
>>> To post to this group, send email to [email protected].
>>> Visit this group at
>>> http://groups.google.com/**group/google-guice?hl=en<http://groups.google.com/group/google-guice?hl=en>
>>> .
>>> For more options, visit
>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>>>
>>
>>
>> Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
>> Injection
>> email: [email protected] :::: mobile: +1 (646) 807-9839
>>
>>
>> --
>> 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
>> google-guice+unsubscribe@**googlegroups.com<google-guice%[email protected]>
>> .
>> To post to this group, send email to [email protected].
>> Visit this group at
>> http://groups.google.com/**group/google-guice?hl=en<http://groups.google.com/group/google-guice?hl=en>
>> .
>> For more options, visit
>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>> .
>>
>>
>>
>
> --
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
