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.

Essentially, if we want stuff to be changed, we want it to be easy, so we need to ensure our design is such that we keep all the changing stuff in one place and independent. This can be done by measuring the afferent (from outside in) and efferent (from inside out) dependencies of classes in the package.

Packages can be classified as stable(difficult to change) and volatile(easy to change). Stable packages must not depend on Volatile one because

- It makes Volatile packages harder to change

- Or It may force stable packages to be changed often, in other words volatile becomes stable

Thus we have to ensure that volatile packages must depend on stable packages.

Lets consider an example where a Class library L depends on the collection class library C which further depends on special memory allocation library M. For execution speed, API of C is modeled after API of M. Now M(a volatile class here)has a serious bug which needs to be fixed. Thus Class C(a stable class)needs to be updated. How does this affect all the classes here?

- Fixing issues in Class M causes API changes in C which requires changes in the header files of Class C

- As API of M reflects in API of C, L also has to be modified too.

Stability

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.

Stability and Dependencies

With the above definition of stability, you don't want to increase stability of the packages as your software can not change easily then. But if the system has been designed well then hard to change packages or stable packages will not change that frequently. Thus, we need to understand the relationship between stability and dependencies.

Consider a following example, Here package x, depends on three other packages. Thus, it is said that x is responsible to the other three packages. On other hand, x does not depend on anything, thus it does not influence any other change. It is said to be independent [3].

(Could you put an image here figure 2-25 on page 23)

Another example, here package y has no packages depending upon it, thus we call it irresponsible. It is very instable package. But there are three other packages that y depends upon, so changes from these three external packages may affect it and thus we say y is dependent.

(Could you put an image here figure 2-26 on page 23)

Thus we need to be careful while designing packages especially lower level packages (which would have more users) and higher level packages (which would tend to have fewer users).