All the design principles focus on getting the dependencies right between classes and then between packages. This enables high reusability and easier maintenance of software applications. As we have seen in Common Closure Principle, packages can be closed only for certain changes, an absolute closure is difficult. To be able to define a dependency chain which can help in localising the changes and create a system which is still flexible but not prone to erroneous changes, we need to look at stability of packages.
Literally, stability can be defined as reliability, dependability, constancy of character or purpose, steadfastness. A package can be considered stable if it is not changed frequently, or if there is no need to change it frequently. Therefore, packages can reliably depend on this stable package. This leads us to
The dependencies between packages in a design should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable that it is.
This principle can go to an atomic level of classes and say that classes should depend on more stable classes only. This is a direct derivation of the Dependency Inversion Principle (DIP).
Lot of times, a single change in a class and hence a package triggers a chain-reaction causing changes to more than expected places. This is a classic case leading to overflow of estimates and sometimes leading to failure. By applying SDP the typical chain reaction can be avoided, as the more stable packages are lower in the chain.
It is important to identify stable packages and packages that change. The packages that are expected to changes should be designed to change and acknowledged accordingly. This information can give a better handle on the changes to be done and the corresponding estimates.
Robert Martin (pdf) defines and illustrates a system of stability metrics to measure stabilities of a package.
One way is to count the dependencies that enter and leave that package. These counts will allow us to calculate the positional stability of the package.
- Ca: Afferent Couplings: The number of classes outside this package that depend upon classes within this package.
- Ce: Efferent Couplings: The number of classes inside this package that depend upon classes outside this package.
- I: Instability: (Ce / (Ca+Ce)): This metric has the range [0, 1]. I=0 indicates a maximum stable package. I=1 indicates a maximally instable package.
Typically, but not always, abstract classes and interfaces are not dependent on others and tend to be more stable as against concrete or implementation classes. This is because the abstract classes or interfaces typically represent the high level design and not the implementation, e.g, an interface called
Logger will be more stable than classes
Back to Design Principles.
Copyright Abhijit Nadgouda.