That's more or less where I'm at, Cedric.
That said, I'm also in favor of "new" for pure raw value types. There
are places where you don't need a seam for testing or for
modularity/decoupling, because you're dealing with something that you
are never going to sanely mock or stub or swap.
Pure value types that aren't used in any persistent configuration role
are examples of these for me. These should be newed and passed in on
the call stack, if needed.
Again, these are judgments, and your design will vary. We all develop
certain styles based on what pains we've felt in our prior applications.
For myself, when I see people injecting Provider<T> everywhere, it
suggests to me that they're either wanting a factory, or have
mis-aligned their scopes and which objects fall in which scopes.
Christian.
On 11 Apr 2013, at 11:18, Cédric Beust ♔ wrote:
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.
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.
