The Principles of Package Coupling
Sep 22 2016
In a previous post, I wrote about the The Principles of Package Coupling, a subset of the Principles of Package Design. The remaining principles make up The Principles of Package Coupling, which which are guidelines on how to reduce coupling among your packages.
The Principles of Package Coupling are:
- The Acyclic-Dependencies Principle
- The Stable-Dependencies Principle
- The Stable-Abstractions Principle
The Acyclic-Dependencies Principle (ADP)
This principle states that one should allow no cycles in the package-dependency graph.
Why is it wise to avoid cycles in your dependency graph?
A package’s dependencies are all of the packages that it depends on, and all of the packages that the dependencies depend on, and all of the packages that the dependencies of the dependencies depend on, and …
In other words, a package’s dependencies are transitive. Consider the dependency graph below.
Specifically, look at package
D. If we decide to make a change to package
D, then we will need to make sure that change is compatible with packages
G. These are all of that packages that transitively depend on
Now, consider the implication if a cycle is introduced where
G depends on
If we have to consider transitive dependencies, then this one additional dependency means that now all the packages depend on all of the packages.
In order to change
D now, we much make sure that the change is compatible with
C. Then there is also the possibility that a change to
D forces a change to
A, which forces a different change in
D. You can see how things could start to get hairy.
The Stable-Dependencies Principle (SDP)
This principle states that one should depend in the direction of stability.
Obviously, this principle is about stability. Though, what is stability, and how do we measure it?
Uncle Bob measures the stability of a package as the number of efferent couplings divided by the sum of the number of efferent couplings and the number of afferent couplings.
However, for simplicity’s sake, we can illustrated this with two diagrams.
Both of the diagrams are stable or instable with respect to package
The diagram on the left demonstrates extreme instability.
A depends on every other package, and is depended on by no packages.
A is dependent. Any one of
A’s dependencies could require
A to change.
The diagram on the right shows extreme stability.
A depends on nothing, and everything else depends on it. Here,
A is independent. Because
A does not depend on anything, no other package could require it to change. On the flip side, because it is the dependee of three other packages, it has a good reason not to change.
So how does this play into the direction of stability?
Basically, this principle says that you should put stable packages in the position of stability and instable packages in the position of instability. If there is a package that is going to have many changes, then it should be depended on by as few packages as possible. If a there is a package that will not change, then it can be depended on by many packages.
The Stable-Abstractions Principle (SAP)
This principle states that a package should be as abstract as it is stable.
Another way of saying this is that a package should to be depended on to the extent that it is abstract, and depend on others to the extent that it is concrete.[PPP]
This suggests that that there are four extremes that a package can fall into.
- Not abstract & Stable
- Abstract & Stable
- Not Abstract & Instable
- Abstract & Instable
Uncle Bob has a name for #1 and #4. He calls them the Zone of Pain and the Zone of Uselessness respectively. #1 means that a package is concrete, and depended on by many other packages. This is a package that would be very hard to change. #4 would be a package that is completely composed of abstractions, but no package is using those abstractions.
The sweet spot is somewhere between Abstract & Stable and Not abstract & Instable.
These and The Principles of Package Coupling are all outlined, in much greater detail, in Chapter 20 of Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin.
[PPP] Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin. - Chapter 20, p. 266