That 3rd class should probably be a feature of B and C that is mixed in some other way, private modules are not the only way to do module composition like that. You can also use the binding dsl to bind multiple variations of a binding (using a loop for example)
On Thu, Jun 25, 2015 at 2:51 PM, Nate Bauernfeind < [email protected]> wrote: > Luke, If you use annotations for everything that you intend to be private > then how do you re-use a class across more than one module? > > For example, suppose I have an interface A. I have two different > implementations B and C. Both B and C are singletons for two different > modules (and each of the two modules are optional at runtime). Now suppose > a have a third class which records metrics about the instance of A for each > module. I would need additional code to bind him properly. Either I write > two providers, or annotate two provider methods and construct each manually > (which is inconvenient in the grand scheme of things). > > Maybe it would be useful for me to see a code snippet (or blog post) that > clarifies your usage pattern. > > Also, it would be nice to hear what you dislike about private modules. > Most [good] software is decomposable and guice modules just the same; it > seems natural to be explicit about what a specific module provides the rest > of the application. > > On Thu, Jun 25, 2015 at 5:26 PM Luke Sandberg <[email protected]> > wrote: > >> use annotations and java visibility to hide implementation details, not >> private modules. >> >> a lot of the remaining private module usecases can be solved by making >> your modules configurable/parameterizable by custom binding annotations >> >> On Thu, Jun 25, 2015 at 7:11 AM, Tavian Barnes <[email protected]> >> wrote: >> >>> PrivateModules are conceptually more complicated because they >>> necessarily involve a hierarchy of injectors instead of just one. As well, >>> you can't expose() everything from a PrivateModule, for example AOP >>> interceptors. So personally I'd recommend only using PrivateModules when >>> necessary. >>> >>> Usually I just hide implementation types by making them >>> package-private. That way no one else can get at them even if they're >>> exposed in the root injector. >>> >>> On Thursday, 25 June 2015 09:04:58 UTC-4, KimJohn Quinn wrote: >>>> >>>> I am wondering what best practices people use when applying private >>>> modules in a large system. >>>> >>>> We currently use a conventional approach of all modules are not private >>>> unless explicitly required. We are considering, as a pattern, making each >>>> major module bind its components privately and only expose its public >>>> interfaces. >>>> >>>> Are there any pros/cons of relying on private modules heavily? >>>> >>>> >>>> -- >>> 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. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/google-guice/32b41b9a-1af0-4177-bb5f-ffd26d591c79%40googlegroups.com >>> <https://groups.google.com/d/msgid/google-guice/32b41b9a-1af0-4177-bb5f-ffd26d591c79%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-guice/CAO9V1ML6HWhrnBr_Gc3MzkV4VNykvi_75aD6neJCQHamJVMAtw%40mail.gmail.com >> <https://groups.google.com/d/msgid/google-guice/CAO9V1ML6HWhrnBr_Gc3MzkV4VNykvi_75aD6neJCQHamJVMAtw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-guice/CAHNex98arYawyL2CbZ-sM0DssaGFgwiUwJvkCpA4XU4sVRv6Zw%40mail.gmail.com > <https://groups.google.com/d/msgid/google-guice/CAHNex98arYawyL2CbZ-sM0DssaGFgwiUwJvkCpA4XU4sVRv6Zw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAO9V1MLDy0XiSupi9br2tLASSws2%3Djc4z78caCJdR-TBQoyx3A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
