Talk:Circular dependency
What is the point of this article? Are circular dependencies acceptable or are they to be avoided ?(the article implies "unavoidable"). Do such dependencies only exist between two classes or can the cycles be larger (e.g., A->B->C->D->A) (the article implies "two"). Do such dependencies only exist in C++ or do they appear in other OO languages? (the article implies c++ is what's important). Yes it's "only" a stub. But without knowing what the intent of having the article is in the first place, it's hard to know how to complete it (or whether it is even worth bothering). I've now improved the article to answer (most of) your questions. Hope it's clearer now. --Fredrik Orderud 13:33, 29 January 2006 (UTC) Who is considering circular dependencies bad practice, and why? I think it's just plain nonsense, especially for types that are part of the same subsystem (so I can't have a Company with a list of Persons Employees, and a Person Employee with a backreference to the Company to which it belongs?). Also, you say that you need to include the definition of one class above the other, which you already show is not true. You need the declaration, not the definition. Forward declaration is not a "trick". If you need to use a forward declaration because you're having a circular dependency, you are including too much header files in the first place. You should only include what you need, and declaring a pointer doesn't mean you need the definition of the class pointed to. Including too much and increasing file dependencies and compile times, now THAT is considered bad practice :). With all that in mind, basically the whole paragraph becomes ridiculous, and I seriously doubt the usefulness of this article as a whole --.oisyn 10:51, 8 November 2007 (UTC) A back-reference from a Person class to a Company class is indeed a bad circular dependency which makes problems as soon as you try to reuse the Person class for something where you don't want to bother the Company. The unwanted circular dependency of Person can and should be resolved by having a Employee class that derives from Person which has a reference to it's employer (class Company). For Employee and Company the circular dependency models the domain and therefor it makes perfect sense. But a plain Person class should not have such a domain specific dependency. --Henon (talk) 08:52, 12 January 2009 (UTC) Of course you're completely correct, it was a bad choice in class naming from my part. Nevertheless, my point still stands, so I've altered my original comment a little. --.oisyn (talk) 17:42, 14 February 2009 (UTC)
 | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||
What is the point of this article? Are circular dependencies acceptable or are they to be avoided ?(the article implies "unavoidable"). Do such dependencies only exist between two classes or can the cycles be larger (e.g., A->B->C->D->A) (the article implies "two"). Do such dependencies only exist in C++ or do they appear in other OO languages? (the article implies c++ is what's important). Yes it's "only" a stub. But without knowing what the intent of having the article is in the first place, it's hard to know how to complete it (or whether it is even worth bothering).
- I've now improved the article to answer (most of) your questions. Hope it's clearer now. --Fredrik Orderud 13:33, 29 January 2006 (UTC)
- Who is considering circular dependencies bad practice, and why? I think it's just plain nonsense, especially for types that are part of the same subsystem (so I can't have a Company with a list of Persons Employees, and a Person Employee with a backreference to the Company to which it belongs?).
- Also, you say that you need to include the definition of one class above the other, which you already show is not true. You need the declaration, not the definition. Forward declaration is not a "trick". If you need to use a forward declaration because you're having a circular dependency, you are including too much header files in the first place. You should only include what you need, and declaring a pointer doesn't mean you need the definition of the class pointed to. Including too much and increasing file dependencies and compile times, now THAT is considered bad practice :). With all that in mind, basically the whole paragraph becomes ridiculous, and I seriously doubt the usefulness of this article as a whole --.oisyn 10:51, 8 November 2007 (UTC)
- A back-reference from a Person class to a Company class is indeed a bad circular dependency which makes problems as soon as you try to reuse the Person class for something where you don't want to bother the Company. The unwanted circular dependency of Person can and should be resolved by having a Employee class that derives from Person which has a reference to it's employer (class Company). For Employee and Company the circular dependency models the domain and therefor it makes perfect sense. But a plain Person class should not have such a domain specific dependency. --Henon (talk) 08:52, 12 January 2009 (UTC)
- Of course you're completely correct, it was a bad choice in class naming from my part. Nevertheless, my point still stands, so I've altered my original comment a little. --.oisyn (talk) 17:42, 14 February 2009 (UTC)
- A back-reference from a Person class to a Company class is indeed a bad circular dependency which makes problems as soon as you try to reuse the Person class for something where you don't want to bother the Company. The unwanted circular dependency of Person can and should be resolved by having a Employee class that derives from Person which has a reference to it's employer (class Company). For Employee and Company the circular dependency models the domain and therefor it makes perfect sense. But a plain Person class should not have such a domain specific dependency. --Henon (talk) 08:52, 12 January 2009 (UTC)
C++
[edit]This article implies that there is a circular dependency between C++ and circular dependencies when in fact there are no dependencies between C++ and circular dependencies as all. Specifically the article seems to imply that C++ depends on circular dependencies and that circular dependencies depend on C++. I can assure you, however, that C++ does not depend on circular dependencies, and in fact, limited C++ code can be written with no dependencies at all or even with non-circular dependencies. Likewise, circular dependencies do not depend on C++, but can in fact, exist in programs written in other languages (as a PHP developer I can prove this).
- The C++ example was just used because this commonly occurs in C++ due to the way the compiler operates. If you want to write a PHP example and include that go ahead. -Rushyo Talk 23:37, 7 August 2008 (UTC)
Um. See [Recursion] —Preceding unsigned comment added by 210.15.222.106 (talk) 01:45, 1 July 2008 (UTC)
Generalization
[edit]This article could be generalized for circular dependencies in software design in general. Some thoughts:
- Definition
A Circular Dependency in a software design is a mutual dependency between two modules which either directly or indirectly depend on each other to function properly.
- Significance
Circular dependencies should be avoided if possible in software design because of their negative effects. Some of these effects are:
- a circular dependency can be a "breach of encapsulation" (see Encapsulation)
- a circular dependency tightly couples two or more modules making each of them unable to be reused in other places without dragging in dependencies on the others.
- circular dependencies can be the cause of a so called "domino effect" which describes what happens when a small change in software that is supposed to be a local change spreads into other modules and has unwanted global effects (i.e. program errors, compile errors).
- a circular dependency might result in infinite recursions or in failures in software programs