We have talked about SOLID, about how to create your classes in order to favour reuse and modifiability. Now, we are going to talk about how to group those classes, creating packages that are right in terms of cohesion, coupling and also favour maintainability.
As software keeps growing in size and complexity, you have to be very careful about how to organize and groups your classes and modules, this REALLY isn’t something that you can do without thinking or analyzing the solution. So, the question is:
How do we decide what goes into one package or another?
As always, Uncle Bob has our backs and outlined 6 principles in his book “Agile Software Development” grouped in those for package cohesion and package coupling.
Principles of Package Cohesion
Reuse-Release Equivalence Principle (REP)
This principle states that within a package, either all of the classes are reusable, or none of them is. A package constructed as a family of reusable classes tends to be most useful and reusable.
“The granule of reuse is the granule of release”
Moreover, each package we depend on should be versioned on its own, so we can for-see when there could be problems when upgrading it.
Common-Reuse Principle (CRP)
“The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all…we would expect to see classes that have lots of dependencies on each other.”
This one is really simple and straight to the point, if classes tend to be reused together, then they belong to the same package.
Common-Closure Principle (CCP)
“The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package and no other packages — This is the Single Responsibility Principle restated for packages.”
A package should not have more than one reason to change. So, we should identify classes that are likely to change for similar reasons and group them together. If the classes are tightly coupled they also belong to the same package.
Package Coupling
Acyclic Dependency Principle (ADP)
"No cycles will be accepted in the dependency graph.”
ADP states that there can be no cycles in the dependency structure, so it should be impossible to follow all the dependencies from one package and end up in the same one.
Stable-Dependencies Principle (SDP)
"Code should depend in the direction of stability”
Packages that don’t change much shouldn’t depend on those that change more frequently. If not, the amount of change that has to be made in the entire system will be huge. So if you have a stable package at the bottom of the tree, this won't make all of its dependents change.
Stable-Abstractions Principle (SAP)
"A package should be as abstract as it is stable"
A stable package should also be abstract so that its stability doesn’t make it not extensible. When a stable package has more abstract classes, these ones can be extended without the need to modify existing code, which is the main goal. Furthermore, an unstable package should be concrete, since its instability allows concrete code to be easily changed.
Bonus Track - SAP and SDP combined constitute:
Dependency Inversion Principle (DIP)
“Depend on abstractions not concretions”