I did a set for feature diagrams for JUnit yesterday. The framework has an interesting structure. I think it's kind of neat that TestResult looks like it has a couple of little groupings internally.. there's a set of methods which wrap the fFailures collection and a set of methods which wrap the fErrors collection. If the methods wrapping those collections weren't public, those little clusters could be candidates for an extract class refactoring. But, as they stand they are just a good example of internal encapsulation in a class --not necessarily anything that is worth extracting out. Sometimes internal encapsulation is just internal encapsulation.
Recently, I've been playing around with algorithms that can detect actionable cases for class extraction in a class based upon these internal dependencies. There's a lot that this sort of graph analysis misses; for instance, you can't see conceptual cohesion. But, when you have ill-mannered code, code that isn't as elegant as JUnit and FIT, it makes sense to look at the natural clusters and see if they are part of a concern that can be factored out. My initial thought is to go after low-hanging fruit: find clusters of natural encapsulation that happen only in private and protected methods. In those cases, at least, it's clear that you could factor out a cluster without impacting clients of the class.
The link is broken for me. It also points to a different domain.
Posted by: Florian | April 11, 2012 at 07:28 AM