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
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>
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 [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.
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 [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.
