Home
Examples
Download
User Guide
1. Usage
2. How Classycle works
3. What Classycle's Analyser measures
4. Dependency Definition File
5. Hints to improve design
API documentation
SourceForge project page

5. Hints to improve design

Some hints for removing cyclic dependencies can be extracted from the analysis Classycle performs. As explained in Chapter 3.2 Classycle calculates for each class/package in the cycle its potential to fragmentize the cycle into smaller subcycles when it is removed from the cycle. Classycle lists the maximum fragment size for each class. The best fragmenters are those classes/packages in the cycle leading to the smallest maximum fragment size. The optimum (best fragment size = 1) is reached when a vertex is found whose removal would turn the cycle into a complete acyclic graph.

4.1 Resolving Class Cycles

Of course removing a class does not make sense from the point of view of a Java application because it needs this class. Fortunately, the same effect can be obtained by replacing the vertex by two vertices in the following way:

All classes in the cycle who depend on A will now depend on A'. Class A' does not depend on any class in the cycle. Of course it can depend on other classes outside the cycle. Class A'' depends on the same classes as the original class A. But other classes in the cycle do not depend on A''. Again classes outside the cycle can still depend on A''. Because the original class A is splitted into A' and A'' there should be a dependency between both. But only A'' depends on A' and not vice versa. Otherwise we would have still the original cyclic dependency.

A general and widely used recipes for splitting of a class A into A' and A'' is the introduction of an interface: Here A' is an interface which is implemented by A''. Sometimes it is possible to split A into two independent concrete classes A' and A''. But this is a rare case.

4.2 Resolving Package Cycles

Package cycles are cured in three or four steps:

Join the packages of a cycle into a big package containing all classes of the original packages.
Detect the strong components (i.e. cycles) of classes in this monster package.
Break up cycles which are large or dealing with different concerns (e.g. view classes and data classes). This is an optional step.
Build new packages which package the strong components.