Cyclic dependencies

Vassilios Karakoidas
2 min readJul 22, 2024

All started when i began to read Diomidis Spinellis’s latest book, titled Code Quality. In page 351, Figure 7.19 shows a cyclic dependency in Xerces and Eclipse.

First thought is that this level of abstraction may be not appropriate to show such an issue all the time. For example, consider that we have three packages, org.example.foo, org.example.bar, and org.example.foobar.

The package org.example.foo has the classes A and B.

package org.example.foo;

public class A {
...
}

and

package org.example.foo;

import org.example.foobar.G;

public class B {
G g_ref;
}

The package org.example.bar has:

package org.example.bar;

import org.example.foo.A;

public class C {
A a_ref;
}

and

package org.example.bar;

public class E {
...
}

The package org.example.foobar has:

package org.example.foobar;

import org.example.

public class F {
E e_ref;
}

and

package org.example.foobar;

public class G {
...
}

The UML diagram the depicts the dependencies follows.

If i am not mistaken, this is a cyclic dependency, but not in our case … why? Because the classes are dependent in pair and they do not form a full cycle. Look at the code some more to see my point. The diagram that shows the real picture follows.

Notations are usefull :), but be always sure that you see the real picture.

--

--

Vassilios Karakoidas

Software Engineer, Software Architect, Gamer and Researcher. Opinions are my own.