|
Question1 - 10+ implementations: If you have lots of implementation or you have a plugin like architecture where new implementations may be added after your main component has already been released then my proposed solution would not scale. If you are in such a situation have a look at multibinders: http://code.google.com/p/google-guice/wiki/Multibindings But if you are sure you will only have a very limited number of implementations and no new ones will be added after release day I would go with an approach similar to my proposal. Simply because I feel it is easier readable and most important it is testable without having to create an injector. Question2 - should it implement Provider<T>: I deliberately did not implement the provider interface. And if you would try to add it to my code you would get a compiler error. I prefer to pass the required data to make the decision which implementation to choose to the method getServiceFor(...). The provider interface on the other hand has only a no-arg method get(). If you would want to implement the provider interface you would have to inject all required information to make the decision into your implementation. This may lead to more complex code when the decision is based on a user action or similar information which is not available beforehand. I agree that in a guice based implementation the usage of the word provider in a class name may not be well suited if the class does not implement the provider interface. You could call the class OrganizationServiceFactory or OrganizationServiceLocator to avoid confusion. On 02/26/2014 03:35 PM, sreenivasu
puppala wrote:
-- 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. For more options, visit https://groups.google.com/groups/opt_out. |
- Coding for Multiple Implementaions for a ser... sreenivasu puppala
- Re: Coding for Multiple Implementaions ... Tim Boudreau
- Re: Coding for Multiple Implementai... sreenivasu puppala
- Re: Coding for Multiple Impleme... Moandji Ezana
- Re: Coding for Multiple Imp... sreenivasu puppala
- Re: Coding for Multipl... Stephan Classen
- Re: Coding for Mul... sreenivasu puppala
- Re: Coding for... Stephan Classen
- Re: Coding for... Juan Pablo Vergara Villarraga
- Re: Coding for... sreenivasu puppala
- Re: Coding for... Stephan Classen
- Re: Coding for... Paweł Cesar Sanjuan Szklarz
