Acyclic dependencies principle
(New page: "The dependency structure between packages must be a Directed Acyclic Graph (DAG)." [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ http://ifacethoughts.net] The Acyc...) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Joey Scarr) |
||
| (10 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | "The dependency structure between packages must be a Directed Acyclic Graph (DAG)." [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ http://ifacethoughts.net] | + | ==Description== |
| + | "The dependency structure between packages must be a Directed Acyclic Graph ( DAG)." [http://ifacethoughts.net/2006/04/10/acyclic-dependencies-principle/ http://ifacethoughts.net] | ||
| − | The Acyclic dependencies principle states that when traversing the package dependency graph, there should be no path from a package back to that package. If there is a path back to the original package, there is a cycle in the graph (ie it is not Acyclic). This occurs when package A depends on package B, and package B depends on package A. This is a transitive relationship, so if package | + | The Acyclic dependencies principle states that when traversing the package dependency graph, there should be no path from a package back to that package. If there is a path back to the original package, there is a cycle in the graph (ie it is not Acyclic). This occurs when package A depends on package B, and package B depends on package A. This is a transitive relationship, so if package B depends on package C, then package C must not depend on package A or B. |
| − | This is important from a deployment point of view, as well as from a maintenance perspective. If the dependency structure is a DAG, then building the application is trivially a traversal of the dependency graph. A cyclic dependency graph can result in problems when building the system. (If package A needs package B, but package B needs package A, which should you build first?). | + | This is important from a deployment point of view, as well as from a maintenance perspective. If the dependency structure is a [http://en.wikipedia.org/wiki/Directed_acyclic_graph DAG], then building the application is trivially a traversal of the dependency graph. A cyclic dependency graph can result in problems when building the system. (If package A needs package B, but package B needs package A, which should you build first?). |
Also, a system with no package cyclic dependencies will be easier to maintain. It will be obvious which packages may be affected by making changes to a specific package; simply traverse the dependency graph from the package that was changed. | Also, a system with no package cyclic dependencies will be easier to maintain. It will be obvious which packages may be affected by making changes to a specific package; simply traverse the dependency graph from the package that was changed. | ||
| + | ==Conflicts== | ||
| + | ===The Visitor=== | ||
| + | The [[Visitor]] pattern contains a cyclic dependency. Here, the concrete visitor depends on the interface of the concrete elements it visits. Similarly, the concrete elements must be familiar with interface of all visiting concrete visitors. | ||
| + | ====Mitigation==== | ||
| + | *Where a visitor pattern is necessary, the ill effects of cyclic dependency can be mitigated by ensuring that cyclically dependent classes are deployed within the same package. | ||
| + | *Bob Martin suggests a solution to this problem in his paper [http://www.objectmentor.com/resources/articles/acv.pdf Acyclic Visitor]. | ||
| + | |||
| + | ==Automatability== | ||
| + | The Acyclic dependencies principle is well suited to Automation. The package structure can be modelled as a directed graph, and can then be tested for cycles using a topological sort algorithm. | ||
| + | |||
| + | ==See Also== | ||
| + | * [[Dependency inversion principle]] | ||
| + | * [[Circular dependency]] | ||
| + | * [[Interface should be dependent on model]] | ||
| + | |||
| + | [http://en.wikipedia.org/wiki/Directed_acyclic_graph Directed Acyclic Graph -Wikipedia] | ||
| + | |||
| + | [[Category:RuleAutomation]] | ||
| + | [[Category:Bob Martin's principles]] | ||
Latest revision as of 03:23, 25 November 2010
Contents |
Description
"The dependency structure between packages must be a Directed Acyclic Graph ( DAG)." http://ifacethoughts.net
The Acyclic dependencies principle states that when traversing the package dependency graph, there should be no path from a package back to that package. If there is a path back to the original package, there is a cycle in the graph (ie it is not Acyclic). This occurs when package A depends on package B, and package B depends on package A. This is a transitive relationship, so if package B depends on package C, then package C must not depend on package A or B.
This is important from a deployment point of view, as well as from a maintenance perspective. If the dependency structure is a DAG, then building the application is trivially a traversal of the dependency graph. A cyclic dependency graph can result in problems when building the system. (If package A needs package B, but package B needs package A, which should you build first?).
Also, a system with no package cyclic dependencies will be easier to maintain. It will be obvious which packages may be affected by making changes to a specific package; simply traverse the dependency graph from the package that was changed.
Conflicts
The Visitor
The Visitor pattern contains a cyclic dependency. Here, the concrete visitor depends on the interface of the concrete elements it visits. Similarly, the concrete elements must be familiar with interface of all visiting concrete visitors.
Mitigation
- Where a visitor pattern is necessary, the ill effects of cyclic dependency can be mitigated by ensuring that cyclically dependent classes are deployed within the same package.
- Bob Martin suggests a solution to this problem in his paper Acyclic Visitor.
Automatability
The Acyclic dependencies principle is well suited to Automation. The package structure can be modelled as a directed graph, and can then be tested for cycles using a topological sort algorithm.
