Sorry - the wording is perhaps overstated. javax.inject.Provider is
merely a standardization of Guice's Provider in order to provide more
compatibility between different DI systems. They occupy the same space
in the design.
And I suppose it's not "internal" to Guice in that it is a public API,
but it is, nevertheless, a part of the DI mechanism. It is a part of
the framework itself rather than merely a signal like @Inject which, as
an annotation, is throw-away if you don't want to use it.
But more importantly, what it isn't is a generalized Factory interface
or pattern, though it bears a similarity to it. It also bears a
similarity to Supplier and any number of other "get me something"
patterns. My point is, it's distinct from the concept of Factory<T> or
Supplier<T> (or even Lazy<T> as Dagger has).
Christian.
On 11 Apr 2013, at 6:14, Tim Peierls wrote:
Are you talking about com.google.inject.Provider or
javax.inject.Provider
or both?
Calling javax.inject.Provider an internal type seems a bit harsh.
--tim
On Thu, Apr 11, 2013 at 3: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.
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.
