Acyclic Dependencies Principle |

Cycled components can only be used together. They can only be tested, reused, deployed and understood together. The bad thing with cycles is that every node on a cycle depends on any other. Having lots of cycles lets explode the number of indirect dependencies within the system. Without early intervention, the system starts to rot. We should therefore avoid dependency cycles within the design layer. That is, no library, package or package tree dependency cycles! This is known as the ## CyclesLet's assume we have cyclic dependencies and want to remove them. Therefore, we want to do some refactoring that modifies our dependency graph to be acyclic. A naive approach would be to list all cycles, break them, one by one, until no cycles are left. Breaking a cycle could be done by removing or reversing a dependency. Let's see how that works. Consider a graph with all pairs of nodes connected by edges into both directions. If we have two nodes, there's exactly one cycle. Adding a third node, we get five cycles: three cycles between pairs of nodes and two cycles containing all three nodes, clockwise and counterclockwise. Now let's increase the number of nodes to – say – ten. Guess how many cycles we get? More than a million! Seems like we better abandon the idea of fiddling around with individual cycles... ## TanglesA Instead of breaking individual cycles, we could try to break tangles! Breaking a tangle means to transform it into an acyclic graph. However, the edges in In graph theory, this is known as a
When looking at a tangled graph, it's often hard to identify the boundaries of a tangle. Its nodes may be spread over the graph, so it's sometimes difficult to see which nodes and edges make up the tangle. With As a side effect, it also reduces the complexity of the graph, because edges between nodes inside and outside of a tangle have been cumulated, now connecting the whole tangle with the outside world. The Acyclic Dependencies Principle is reflected by the |

Next > |
---|