Sorry, it's a mistake ( while writting the summary, I mixed up both 1 and 2 flaws )
1/ escape line 2/ doesn't force you to change ErrorManager, but to change all the injectee-side code 3/ best for evolution (no code change in the injectee side) Yep 2/ is just a type safe 4/. for me I think there might be a solution using Scope but I can't figure out how ! Scope are a bit complicated for me right now. Based on the name, I Imagined Scope could have worked as "namespace" but I do understand scope (yet ?) On 27 jan, 15:15, Peter <[email protected]> wrote: > Hi Eric! > > 4/ use the @Named annotation via Names.named("xml"). > > So, is the second approach something like a type safe Named? > > > 2/ forces you to change the interface ErrorManager > > Why do you need to change the interface? > > Regards, > Peter. > > On Jan 27, 12:41 pm, eric <[email protected]> wrote: > > > > > Hi, > > > I'm writting a "small" tutorial for my fellows, and I feel that this > > part was worth sharing with you, to get feedback and discussion on it. > > Thanks. > > > Dealing with multiplicity in DI. > > > Multiplicity is always a pain. Unless you have a Singleton > > (manytoOne) , or oneToOne, all the other cases are complicated. > > OneToOne is the default multiplicity for guice. Singleton is easily > > configured in a module. > > > Though, complicated case are very frequent. Some are design flaw, but > > you can't expect every design to be perfect, and some are not. > > > For instance, I have "several" ErrorManager"s in my "eclipse-like" > > application, one for each type of editors, and one for general > > purpose. > > > How to I get the right ErrorManager ? > > > I'll list all the way I know to deal with it. Not all behave the same, > > all have pro and cons. > > > 1/ without Guice > > > Design a singleton service that handles a collection of ErrorManager, > > and then dispatch errors to the appropriate sub ErrorManager. > > > You'll have to redesign the ErrorManager, so it can take as parameter > > the type of Editor, and redispatch to the appropriate ErrorManager. > > > In Guice, you have converted a ManytoMany multiplicity into a > > Singleton, and handle the multiplicity by "hand". > > > 2/ With annotated bindings > > > You can create an ErrorScope Annotation, that has the Editor Type as > > parameter. > > > Then in you injectee, you'll do: > > > @Inject ErrorScope( XMLEditor.TYPE) ErrorManager manager; > > > An in your Module: > > > bind(ErrorManager.class).annotatedWith(ErrorScope(XMLEditor.TYPE) ).to > > ( XMLErrorManager.class); > > > 3/ With private modules > > > You can inject each Editor within it's own private Module. That means > > it will have access to every bindings, plus the one you defined at > > module level. > > > Then in you injectee will look like > > > @Inject ErrorManager manager; > > > In your main Injector (or in the parent module) : > > > Injector i = Guice.createInjector( new XMLEditorModule(), new > > JavaEditorModule() , ...) > > > Where XMLEditorModule extends PrivateModule instead of abstractModule, > > and is configured as follow > > > bind(ErrorManager.class).to(XMLErrorManager.class); > > > Is there other ways to handle this example of multiplicity ? > > Which one is the best for you ? > > > For me, 1/ is an escape line > > 2/ forces you to change the interface ErrorManager and change all the > > code that was using the previous interface. > > 3/ is the best one, but increases the complexity of configuring your > > modules. -- 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.
