Functional issues of cyclic dependencies

[Jack]

Hi,

i've read some articles on cyclic dependencies, that they are bad, very bad. But i can't find any real example of functionnal (!= design) issue with them.

Do you know any ?

 

[Daniel Pitts]

Hi,

i've read some articles on cyclic dependencies, that they are bad, very
bad. But i can't find any real example of functionnal (!= design) issue
with them.

Do you know any ?

Cyclic dependencies in runtime code isn't bad, but might be an
indication of highly coupled design if it is a static cyclic dependency.
What articles have you read? A reference would be nice.

 

[Jack]

Daniel Pitts a écrit :

Cyclic dependencies in runtime code isn't bad, but might be an
indication of highly coupled design if it is a static cyclic dependency.
What articles have you read? A reference would be nice.

well, using google, i've read:

http://www.kirkk.com/blog/index.php?itemid=30
- avoiding cyclic dependencies at class/package level avoid them in jars


http://chasethedevil.blogspot.com/2006/10/how-jdepend-changed-my-java-packaging.html
- build system becomes overly complicated
- making jars is difficult


http://architecturerules.googlecode.com/svn/docs/cyclic-dependencies.html

 

[Kevin McMurtrie]

Hi,

i've read some articles on cyclic dependencies, that they are bad, very bad.
But i can't find any real example of functionnal (!= design) issue with them.

Do you know any ?

Why would it be a functional issue? It's only a design issue in that
the complexity of maintenance can become unmanageable. For a small
package that performs a specific task, cyclic dependencies may be a
perfectly elegant design. When cycles go beyond the package scope, you
increase the risk of overlapping cyclic references prohibiting any
changes to the code (spaghetti code).

 

[Jack]

Kevin McMurtrie a écrit :

Why would it be a functional issue? It's only a design issue in that
the complexity of maintenance can become unmanageable. For a small
package that performs a specific task, cyclic dependencies may be a
perfectly elegant design. When cycles go beyond the package scope, you
increase the risk of overlapping cyclic references prohibiting any
changes to the code (spaghetti code).

That's the most persuasive point i've read.

But still, when i modify a method, i must check all the call sites. Whether the call sites are in the same package doesn't change the difficulty, from my experience.

 

[Daniel Pitts]

Kevin McMurtrie a écrit :

That's the most persuasive point i've read.

But still, when i modify a method, i must check all the call sites.
Whether the call sites are in the same package doesn't change the
difficulty, from my experience.

Right, but if you need to change class A, but it affects class B, which
affects class C, which in turn affects class A, whoops have to change B
again. It becomes difficult to effect change in cyclic dependencies.
Once you notice cyclic dependencies getting out of control, you can
easily decouple elements with an event system.

 

[Patricia Shanahan]

Hi,

i've read some articles on cyclic dependencies, that they are bad, very
bad. But i can't find any real example of functionnal (!= design) issue
with them.

Do you know any ?

In addition to the points that have already been made, it is easier to
unit test code without cyclic dependencies.

Any subtree, down to a leaf class that depends on nothing else, can be
tested as a unit, without it caring whether it is being used by one of
its normal callers or by a unit test.

Testing a class that depends on the classes that use it tends to require
more scaffolding.

Patricia