Theory is, that classes which strongly know and use each other should be in the same package (using package visibility for functions that are not used by the rest of the application), thus forming a concise, understandable interface. [Well-known classes (accessed from almost everywhere, such as loggers) should go to their own package, call it
Assume a code base of several hundred Java files, distributed rather liberally over about six dozen packages, most methods declared
public (aside from some
private ones), and rather obscure relations between classes. (No clear entry points either, since methods are called from a JSF infrastructure, if that matters. There may be some
main() methods, but they are usually not used.)
Did someone ever think about applying a clustering approach to group such a large set of Java classes into packages? I wonder whether and how this would be possible, either to outline the strength of relations between classes as help to manual clean up, or even to automatically reorganize the code somehow.
The distance measure could involve the number of functions required to be declared
public, and the number of package
import statements (meaning those ending with a
.*) that are necessary for the code to compile. Since the algorithmically “best” answer to that question would be to have all classes in one package (does not require any public methods or imports any more, which is not what I want), it seems to me that a hierarchical clustering approach would be the best (leaving the final granularity of packages as a decision to humans), but maybe there are better approaches I am not aware of.
I tried to find information on that topic, but searching for “Java” and “clustering” only brought me to pages explaining how to implement clustering with Java, which is not what I am looking for. (Of course, an approach may well be implemented in Java as well, since it may be realized using introspection. But that’s not important to my question.)