CSC/ECE 517 Fall 2009/wiki1b 13 zz

Bob Martin's Stable Dependencies Principle says, "The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is."

Bob Martin

Robert C. Martin (Uncle Bob) defines the domain of design patterns to be the architecture of systems modules (packages, classes and components) and their interconnections. His design patterns address the four major reasons for failure of the systems: rigidity, fragility, immobility and viscosity [1].

Following are the list of few design principles quoted by him to avoid the pitfalls associated with unsuccessful software engineering, Reuse/Release Equivalence Principle, Common Closure Principle, Common Reuse Principle, Acyclic Dependencies Principle, Staple Dependencies Principle, Stable Abstraction Principle.

The objective of this article is to discuss in detail Stable Dependencies Principle. Each of the four problems discussed above can be caused by improper dependencies between the modules of the software. It is the dependency architecture that degrades the ability of the software to be maintained. The Stable Dependencies Principle is one of the principle which discusses its concern with coupling of packages, or the degree to which they rely on each other.

Stable Dependencies Principle

Principle: The dependencies between packages should be in the direction of the stability of the packages. A package should only depend upon packages that are more stable than it is.

[have to exagerate here with respect to basic definition]. To explain the principle in detail, we need to first understand few terms like stability, dependencies etc first.

Stability and Dependencies

What does stability mean? By simply goggling stability, we get definitions like resistance to change, reliability etc [2]. Thus it roughly means "hard to change", whereas instability means "easy to change".

Consider an example, in which you stand a penny on its side. Is this penny stable in that position? Mostly people would answer a no, even though it does not change its position for a very long time. Thus, stability has nothing directly to do with the frequency of change. It more relates to the amount of work required to make a change. The penny is not stable because it takes little work to topple it.

Thus stability of a software package would depend on various factors like size, complexity, clarity, etc. But with respect to our principle, stability focus on a different factor. A software package would be difficult to change, if it has lots of other software packages depend on upon it. Thus a package with lots of incoming dependencies is very stable because it requires a great deal of work for any change to propagate with all the dependent packages.