In this kind of situation I would try to put my non-reusable code behind [well-thought] interfaces as much as possible. Think about all the [known] use-cases and really try and separate the common logic from the custom logic. If you can hide the state behind a logical interface that has always been a huge win in my experiences.
Also keep in mind the scope of the re-usability .. if you expect others to use it in non-guice scenarios, try hard to separate the needed Guice dependency into a separate maven/project module (basically a Guice convenience package). If the re-use is from within a single application, then assisted inject factories are the easiest way to go (easier than child injectors). If you choose to create a separate GuiceModule that brings all of the components together then be explicit about what things should be externally available (i.e. any implementation of your interfaces should be defined in a different GuiceModule (parent or sibling of your re-usable component)). Consider using interfaces for as many of the internal classes as makes sense ... because if someone doesn't like the default implementation then they can still easily create an override. I have previously used child injectors to create large object graphs that were configured by a couple of minor fields. I was able to reduce all sorts of awkward overhead by doing this. For example, I created a multi-bound list of tags that could be injected at any point in the graph to attach the tags to any metrics. There was a system that was in charge of constructing a new child injector, starting up the Managed classes and for shutting them down when they were no longer needed. It may have been what you're calling boiler plate, but I was extremely satisfied with the end result. I'm actually currently planning on going back to introduce a handful of interfaces (which I didn't originally think of doing) with the goal of making that part of that application easily plugin-able (which I'm anticipating will make it a lot friendlier for open sourcing). Nate On Tue, Aug 27, 2013 at 4:07 AM, <[email protected]> wrote: > Hi, > > Guice has had a big impact with the things I code, particular in > developing and bringing together a modular system + then the testing that > goes with it. > > However, I am struggling to find a nice way to do reusable components and > in part is due to my inexperience with all of this. > > Examples of reusable components may be tabs in a browser or say in an IDE > having drop in components like an n number of editors. > > So with the editors you have many classes that work together to make it > happen and you need to it reusable / many concurrent uses some unique > state. And when you close the editor, you may need to invoke the release of > services / files they handle. > > I see three ways: > 1. Factory / bioler plate code. > 2. Child injectors, still requires a factory + bioler plate for the > lifecycle. > 3. A custom scope but have to manage the scope + entry/exit > > I dislike the first option, too much boiler plate. The second seems to > work well and is probably the avenue I'm going down at the moment. The 3rd > is what I am most confused about, everywhere I read says custom scopes are > bad yet the Session and Request scope of servlets seem very handy and given > I essentially need to manage state it seems like it is the answer. > > Any help would be great thanks. > > Thanks, > Jon > > > > > > -- > 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. > -- 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.
