Dealing with a Circular Dependency
up vote
9
down vote
favorite
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.
java circular-dependency
|
show 3 more comments
up vote
9
down vote
favorite
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.
java circular-dependency
1
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.
– Mecki
Mar 30 '11 at 17:59
1
well, i dont know ... supposing is an anti-pattern i want to avoid ! and for educational purposes, to check different design possibilities.!
– tropicana
Mar 30 '11 at 18:03
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.
– Mecki
Mar 31 '11 at 11:48
1
@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.
– andersoj
Mar 31 '11 at 11:51
1
@Chris: If you give us an example of your circular dependent classes, we can give better advice.
– Paŭlo Ebermann
Mar 31 '11 at 11:56
|
show 3 more comments
up vote
9
down vote
favorite
up vote
9
down vote
favorite
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.
java circular-dependency
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.
java circular-dependency
java circular-dependency
edited 2 days ago
syntagma
12.2k1147102
12.2k1147102
asked Mar 30 '11 at 17:52
tropicana
70911420
70911420
1
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.
– Mecki
Mar 30 '11 at 17:59
1
well, i dont know ... supposing is an anti-pattern i want to avoid ! and for educational purposes, to check different design possibilities.!
– tropicana
Mar 30 '11 at 18:03
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.
– Mecki
Mar 31 '11 at 11:48
1
@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.
– andersoj
Mar 31 '11 at 11:51
1
@Chris: If you give us an example of your circular dependent classes, we can give better advice.
– Paŭlo Ebermann
Mar 31 '11 at 11:56
|
show 3 more comments
1
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.
– Mecki
Mar 30 '11 at 17:59
1
well, i dont know ... supposing is an anti-pattern i want to avoid ! and for educational purposes, to check different design possibilities.!
– tropicana
Mar 30 '11 at 18:03
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.
– Mecki
Mar 31 '11 at 11:48
1
@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.
– andersoj
Mar 31 '11 at 11:51
1
@Chris: If you give us an example of your circular dependent classes, we can give better advice.
– Paŭlo Ebermann
Mar 31 '11 at 11:56
1
1
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.
– Mecki
Mar 30 '11 at 17:59
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.
– Mecki
Mar 30 '11 at 17:59
1
1
well, i dont know ... supposing is an anti-pattern i want to avoid ! and for educational purposes, to check different design possibilities.!
– tropicana
Mar 30 '11 at 18:03
well, i dont know ... supposing is an anti-pattern i want to avoid ! and for educational purposes, to check different design possibilities.!
– tropicana
Mar 30 '11 at 18:03
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.
– Mecki
Mar 31 '11 at 11:48
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.
– Mecki
Mar 31 '11 at 11:48
1
1
@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.
– andersoj
Mar 31 '11 at 11:51
@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.
– andersoj
Mar 31 '11 at 11:51
1
1
@Chris: If you give us an example of your circular dependent classes, we can give better advice.
– Paŭlo Ebermann
Mar 31 '11 at 11:56
@Chris: If you give us an example of your circular dependent classes, we can give better advice.
– Paŭlo Ebermann
Mar 31 '11 at 11:56
|
show 3 more comments
3 Answers
3
active
oldest
votes
up vote
6
down vote
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?
+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.
– Mark McKenna
Oct 5 '11 at 16:30
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.
– jmg
Oct 6 '11 at 8:21
add a comment |
up vote
5
down vote
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
Downvoter-- why?
– andersoj
Mar 4 '12 at 23:38
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)
– sceiler
May 19 '16 at 6:59
add a comment |
up vote
2
down vote
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.
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
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?
+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.
– Mark McKenna
Oct 5 '11 at 16:30
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.
– jmg
Oct 6 '11 at 8:21
add a comment |
up vote
6
down vote
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?
+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.
– Mark McKenna
Oct 5 '11 at 16:30
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.
– jmg
Oct 6 '11 at 8:21
add a comment |
up vote
6
down vote
up vote
6
down vote
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?
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?
answered Apr 3 '11 at 11:02
jmg
6,06611320
6,06611320
+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.
– Mark McKenna
Oct 5 '11 at 16:30
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.
– jmg
Oct 6 '11 at 8:21
add a comment |
+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.
– Mark McKenna
Oct 5 '11 at 16:30
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.
– jmg
Oct 6 '11 at 8:21
+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.
– Mark McKenna
Oct 5 '11 at 16:30
+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.
– Mark McKenna
Oct 5 '11 at 16:30
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.
– jmg
Oct 6 '11 at 8:21
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.
– jmg
Oct 6 '11 at 8:21
add a comment |
up vote
5
down vote
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
Downvoter-- why?
– andersoj
Mar 4 '12 at 23:38
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)
– sceiler
May 19 '16 at 6:59
add a comment |
up vote
5
down vote
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
Downvoter-- why?
– andersoj
Mar 4 '12 at 23:38
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)
– sceiler
May 19 '16 at 6:59
add a comment |
up vote
5
down vote
up vote
5
down vote
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
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
edited May 23 '17 at 12:09
Community♦
11
11
answered Mar 31 '11 at 11:56
andersoj
17k64871
17k64871
Downvoter-- why?
– andersoj
Mar 4 '12 at 23:38
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)
– sceiler
May 19 '16 at 6:59
add a comment |
Downvoter-- why?
– andersoj
Mar 4 '12 at 23:38
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)
– sceiler
May 19 '16 at 6:59
Downvoter-- why?
– andersoj
Mar 4 '12 at 23:38
Downvoter-- why?
– andersoj
Mar 4 '12 at 23:38
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)
– sceiler
May 19 '16 at 6:59
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)
– sceiler
May 19 '16 at 6:59
add a comment |
up vote
2
down vote
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.
add a comment |
up vote
2
down vote
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.
add a comment |
up vote
2
down vote
up vote
2
down vote
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.
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.
edited Sep 22 '17 at 10:19
Japheth Ongeri - inkalimeva
2,33552142
2,33552142
answered Apr 3 '11 at 10:40
pth - Structure101
964
964
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f5490132%2fdealing-with-a-circular-dependency%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
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.
– Mecki
Mar 30 '11 at 17:59
1
well, i dont know ... supposing is an anti-pattern i want to avoid ! and for educational purposes, to check different design possibilities.!
– tropicana
Mar 30 '11 at 18:03
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.
– Mecki
Mar 31 '11 at 11:48
1
@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.
– andersoj
Mar 31 '11 at 11:51
1
@Chris: If you give us an example of your circular dependent classes, we can give better advice.
– Paŭlo Ebermann
Mar 31 '11 at 11:56