+1 On Mon, Jul 9, 2012 at 5:36 PM, Sergiu Dumitriu <[email protected]> wrote:
> Hi devs, > > Short version: > > I'd like to increase the allowed maximum value for the Class Fan-Out > Complexity checkstyle rule from 20 to 25, since a bare component already > uses 1 to 4 imports, and the 20 rule was set before we had components. > > > Long version: > > The Class Fan-Out Complexity metric measures how many other classes are > used by a class. Keeping this to a small value is a good goal, since it > favors loose-coupling, small and independent classes, and makes it harder > to put more than one responsibility in a single class. > > However, there are several problems: > > One is that this counts utility classes and interfaces, such as > java.util.List, and a fairly complex class uses more than one such utility > class; they usually come in pairs (the interface and the implementation). > And more and more classes are using apache-commons utilities like > StringUtils or IOUtils, which are just shortcut helper methods that could > be implemented in a few lines of code, so we're trading one import for > reduced code complexity, which is a good thing, even though apparently it's > increasing the Fan-Out measure. > > Another is that a bare Initializable component implementation will import: > - its component role interface > - Initializable and InitializationException > - Logger > > And since good libraries also follow the "many small classes" paradigm, > barely using some of our dependencies will add a lot of imports. For > example, the LucenePlugin has 25 org.apache.lucene.* imports just for > initializing the server and sending search requests. > > While the current maximum, 20, is enough for the majority of our classes > and interfaces, I've found myself often enough trying to refactor a class > to get down from 23 or even 21 imports, and usually I find myself doing > ugly tricks, keeping the actual code complexity the same or even worse. > Best case is that I extract an extra class that just contains the > non-public utility methods that were initially in the component > implementation, but that class is meaningless out of the context of its > parent class, so that is also a bad decision, IMHO. > > So, I propose to increase the Fan-Out limit to 25, while keeping the > requirement that classes should be kept as small as possible. > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > > ______________________________**_________________ > devs mailing list > [email protected] > http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs> > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
