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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> 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 [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
