I should throw this on a wiki or something.
Christian.
On May 16, 2012, at 6:10 AM, jordi wrote:
> Bubba, I think that Christian responded to your questions in a very
> "bookmarkable" way ;)
>
> On Sun, May 13, 2012 at 4:51 PM, Christian Edward Gruber <cgru...@google.com>
> wrote:
> So here's a hello-worldish example, entirely off the top of my head:
> ----
> Foo <- consumable
> Bar <- consumable (product of a transformation)
> FooProcessor <- collaborator
> Logger <- collaborator
> LookupService <- collaborator
> @Named("lookup.url") String processor <- configuration
> ----
> And the classes would look sort of like this (assuming you used
> AssistedInject to create your Foo objects.
>
> ----
> interface FooProcessor {
> Bar transformFoo(Foo foo);
> }
>
> interface Foo {
> Integer getBaz();
> }
>
> interface Bar {
> Integer getTransformedBaz();
> }
>
> /** Factory interface used by AssistedInject to auto-wire a factory */
> interface FooFactory {
> Foo create(Integer baz);
> }
>
> class FooImpl {
> private final Integer baz;
> private final Logger logger;
> @Inject public FooImpl( @AssistedInject Integer baz, Logger logger) {
> this.baz = baz; // "Injected" through the factory create method.
> this.logger = logger; // Injected from Guice
> }
> }
>
> class FooProcessorImpl {
> // fields
> @Inject FooProcessorImpl(Logger logger, LookupService lookupService) {
> // field assignments
> }
> public Bar transformFoo(Foo foo) {
> Precondition.notNull("foo", foo);
> return new BarImpl(lookupService.lookup(foo.getBaz()) * SOME_CONSTANT);
> }
> }
>
> class LookupService {
> // fields
> @Inject public LookupService(@Named("lookup.url") String lookupUrl) {
> // field assignments
> }
> public Integer lookup(Integer int) {
> // lookup integer from remote service via the lookup url.
> }
> }
> ----
>
> So, Foo and Bar are passed around on the call stack, and consumed and created
> by the collaborators (one collaborator of which is an auto-generated
> FooFactory implementation created by the AssistedInject extension system).
> The collaborators delegate different responsibilities to each other, and the
> configuration contextualizes collaborators.
>
> LookupService injects configuration - a named value, presumably wired into
> Guice via Names.bindProperties(Properties p) or jCommander+gCommander or
> something similar.
>
> This is just how I think of things - a useful breakdown. But, generally, I
> find that when I segregate responsibilities like this, I have far more
> composable code, and it becomes quickly clear whether something shoudl be
> injected or managed by factories or other services.
>
> cheers,
> Christian.
>
>
>
>
> On May 12, 2012, at 12:29 PM, Bubba 42 wrote:
>
>> Many thanks guys for the input.
>>
>> Is there an example (Hello World level of complexity) which
>> illustrates the collaborators, configuration, and consumables
>> stereotypes?
>>
>> I'd be happy to put one together if it'd benefit folks -- but would
>> need help.
>>
>> Thanks.
>>
>> On May 11, 5:23 pm, Christian Edward Gruber <cgru...@google.com>
>> wrote:
>>> Please don't inject value classes, generally speaking.
>>>
>>> I tend to think of dependencies in three kinds - collaborators,
>>> configuration, and consumables. Consumables are value classes that are
>>> consumed by and transformed by your collaborators, in the context of your
>>> configuration. Generally consumables are passed on the function call stack
>>> through parameters, whereas collaborators should be injected (for
>>> testability, decoupling, and all the various other reasons). Configuration
>>> may be passed through either, but pick a strategy and go with it.
>>>
>>> That's my basic position. AssistedInject is wonderful, but slightly missed
>>> named - think of it as "Assisted Auto-Wiring of Factories." It's a good
>>> thing.
>>>
>>> The above isn't to say you "can't" do it, and several frameworks built on
>>> top of guice or other DI systems do just that, but it's tricky and very
>>> likely to get subtle implicit behaviour that's hard for other developers to
>>> reason about. Common cases are for things like "User" objects to be
>>> injected into session-scoped objects. In that case, a user is not
>>> consumable data, but "configuration" - the context in which other things
>>> are mutated and created by the collaborators. But it's important that you
>>> get your mind clear about what's what in your system so you can apply a
>>> consistent strategy to it all.
>>>
>>> Christian
>>>
>>> On May 11, 2012, at 7:05 AM, jordi wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> In case you really need to inject value classes, Guice does that for you
>>>> for free. If you @Inject a Person (non-scoped), every time will give a new
>>>> Person.
>>>
>>>> But I can't figure out why a simple value class should be managed by
>>>> Guice. In this case I'm sure that's easier and clearer to just use a
>>>> regular, old-fashioned new.
>>>
>>>> If what you're looking for is to inject a Service in conjunction with some
>>>> value class, take a look at Assisted Inject [1]
>>>
>>>> hth,
>>>> jordi
>>>
>>>> [1]http://code.google.com/p/google-guice/wiki/AssistedInject
>>>
>>>> On Thu, May 10, 2012 at 10:45 PM, Bubba 42 <bubba424...@gmail.com> wrote:
>>>> Hi,
>>>
>>>> I've been unable to find a suitable answer to this question.
>>>
>>>> If I understand this correctly: Dependency Injection can be used to
>>>> instantiate service objects -- object that essentially abstract away
>>>> some computational service ... for example (an instance of this class
>>>> would essentially be stateless, save for resources that it might be
>>>> plugged into such as SimpleMath.properties, and I would expect that
>>>> there would be small number of instances of this class per application
>>>> instance say under 5):
>>>
>>>> class SimpleMath {
>>>
>>>> public int addTwoNumbers (int n1, int n2) {
>>>> return n1 + n2;
>>>> }
>>>
>>>> public int multiplyTwoNumbers (int n1, int n2) {
>>>> return n1 * n2;
>>>> }
>>>
>>>> }
>>>
>>>> Now can DI be used to instantiate value objects (for the lack of a
>>>> better word). By a value object I mean an object that has state and
>>>> the methods are impacted by that state, for example (as opposed to the
>>>> previous class I would expect there to be hundreds or thousands of
>>>> instances of this class):
>>>
>>>> class Person {
>>>
>>>> int age;
>>>> int weight;
>>>> String fname;
>>>> String lname;
>>>> // and so on
>>>
>>>> public String hail() {
>>>> return "Hello to you to, I am " + fname + " " + lname;
>>>> }
>>>
>>>> public String howOldAreYou() {
>>>> return "I don't really like talking about my age but I'm " + age +
>>>> " years young";
>>>> }
>>>
>>>> // and so on
>>>
>>>> }
>>>
>>>> Thanks.
>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "google-guice" group.
>>>> To post to this group, send email to google-guice@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> google-guice+unsubscr...@googlegroups.com.
>>>> For more options, visit this group
>>>> athttp://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 google-guice@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> google-guice+unsubscr...@googlegroups.com.
>>>> For more options, visit this group
>>>> athttp://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 google-guice@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-guice+unsubscr...@googlegroups.com.
>> 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 google-guice@googlegroups.com.
> To unsubscribe from this group, send email to
> google-guice+unsubscr...@googlegroups.com.
> 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 google-guice@googlegroups.com.
> To unsubscribe from this group, send email to
> google-guice+unsubscr...@googlegroups.com.
> 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 google-guice@googlegroups.com.
To unsubscribe from this group, send email to
google-guice+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-guice?hl=en.
