Private Modules

[KimJohn Quinn]

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?

[Tavian Barnes]

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.

[Nate Bauernfeind]

I've found that despite a few drawbacks, private modules are the way to go. I seem to end up with complicated object graphs and have had some serious issues (customer affecting) when something is used that was not intentionally to be around for public consumption0 (like a single threaded ScheduledExecutorService that gets locked up by an unexpected user). 

The only issue I really run into between the differences is with type listeners, they only receive exposed / public objects. So I've always had to bind my listeners inside of private modules. (Note: exposed objects get listened to more than once which is ok in my use case). This hasn't been a huge drawback, and is worth the guarantee of safety as a code base (and its development team) grow.

--
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 google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
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.
For more options, visit https://groups.google.com/d/optout.

[Luke Sandberg]

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

[Nate Bauernfeind]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAO9V1ML6HWhrnBr_Gc3MzkV4VNykvi_75aD6neJCQHamJVMAtw%40mail.gmail.com.

[Luke Sandberg]

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)

To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/CAHNex98arYawyL2CbZ-sM0DssaGFgwiUwJvkCpA4XU4sVRv6Zw%40mail.gmail.com.