+1 I've seen many of the same problems, unfortunately strict rules and automation can't always tell good designs from bad.
Caleb On 07/09/2012 11:36 AM, Sergiu Dumitriu 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. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
