Dealing with a Circular Dependency
Asked Answered
C

3

12

I wonder if someone can advise on any good ways to break a circular dependency between 2 classes in Java.FindBugs proposes the use of interfaces so i wonder if someone has any good experience with this type of problem.

Catarinacatarrh answered 30/3, 2011 at 17:52 Comment(8)
What is wrong with circular references in the first place? Why would you want to break them? Maybe you should point this out in your question.Naseby
well, i dont know ... supposing is an anti-pattern i want to avoid ! and for educational purposes, to check different design possibilities.!Catarinacatarrh
Circular refs are an anti-pattern? Says who? The Java GC has no problem with them for instances (only a GC that use pure reference counting would have such an issue) and the compiler has no issue with them at compile time, other than that you must compile both classes at the same time, so the compiler is able to resolve the dependencies. BTW, you missed an important tag: java. I'll fix the tags for you.Naseby
@Mecki: Circular class dependencies are a different thing than cycles in the object graph at runtime. I'd agree that circular class dependencies should be avoided where possible, and use of interfaces to break the dependency is a good approach.Intercession
@Chris: If you give us an example of your circular dependent classes, we can give better advice.Ensoul
Related #4993360Intercession
Possible dupe #4007951Intercession
I wrote an article about this some time ago: blog.schauderhaft.de/2011/07/17/breaking-dependency-cylcesSchooner
F
9

Circular dependencies aren't always to be avoided. I'd avoid them in the large, but keeps in small tight corners of a system. In the large, i.e if data access layer and the representation layer of J2EE app circular dependent, I'd say that is a bad thing, because it means that everything has to be compiled in one go and testing is nightmare. But, it's no problem if a list data-structure and its iterator type are circular dependend.

As Findbugs suggests use interfaces to break a circular dependency. I.e introduce a interface for at least one type of the circle and make the other classes use the interface everywhere. Do you need example code?

Fides answered 3/4, 2011 at 11:2 Comment(2)
+1. Good design methodologies are good by virtue of having a clear benefit. In the specific circumstance of a collection and its (lazy) iterator for example, introducing a new interface simply to break the cycle is overkill. However, I would argue this: only use circular dependencies in circumstances where you can include all but one of the dependencies as inner or nested classes. In fact by using inner classes in this way you can avoid many circular dependency alerts, by using the implicit container reference that the inner class keeps.Acaroid
By using the implicit reference of inner classes you might avoid warning of tools, but your code still has circular references. But as I said, I'd advice to make the circles as small as possible - not to avoid them at all costs. And by using inner classes you do that.Fides
I
6

Suggest reading about the dependency inversion principle, e.g. What is the Dependency Inversion Principle and why is it important? or http://en.wikipedia.org/wiki/Dependency_inversion_principle

Intercession answered 31/3, 2011 at 11:56 Comment(1)
Probably because of the missing context around your linked URLs. URLs are encouraged for further reading but the answer should contain some context and the essence of the URLs. Please see this: stackoverflow.com/help/how-to-answer (Provide context for links)Highclass
R
4

There's a blog post here on how Restructure101 was used to remove cyclic dependencies, "tangles", from Junit and a presentation from the Lausanne JUG on how it was used to remove tangles from Icefaces.

As for the debate on whether cyclic dependencies are bad, I suggest reading Uncle Bob's Solid Principles.

Disclaimer: I work for Headway Software the developers of Restructure101.

Rakeoff answered 3/4, 2011 at 10:40 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.