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.

It is a very simple and atomic principle. It is a direct derivation of the Dependency Inversion Principle . This principle enables high reusability and easier maintenance of software applications. To explain the principle further we need to understand a few terms like stability, dependencies etc in more detail.

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 [3].

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 [4].

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.

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).

What does the Principle say?

After explaining the relationship between stability and dependencies, this seems to be an obvious principle. Essentially, if we want packages or classes to change, we want it to be easy, and thus we isolate the unstable packages or classes and make them independent. It helps to define dependency chain which helps to localize the changes but at the same time helps to keep the system flexible [5].

A simple way to arrange packages would be to classify them 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 [6].

Consider an example which would explain the above scenario. 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 has a serious bug which needs to be fixed. Thus Class C 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 Metrics

Uncle Bob also defined stability metrics to the stability of the packages. These metrics determine the stability of a package which is calculated by counting the number of dependencies that enter and leave the package [7].

The Instability metric I is given as

I = Ca/(Ca +Ce)

where,

Ca --> The number of incoming dependencies or number of classes or packages that depend upon classes within this package or Afferent Couplings

Ce --> The number of outgoing dependencies or number of classes inside this package that depend upon classes outside this package or Efferent Couplings

The value of I is always between 0 and 1.

- I = 0 is a Stable Package. In this case, other packages have a dependency on this package but it does not depend on any other outside packages, hence responsible and independent.

- I = 1 is an Instable Package. Here, no other packages have a dependency on this package but this package depends on the other outside packages, hence irresponsible and dependent.

The values Ca and Ce are calculated by counting the number of classes outside the package that have dependencies with the classes inside the package being considered. A figure explaining how the metric can be calculated is shown below

In the above example we can compute the Instability metric of the package in the center. Here the dashed arrows represent package dependencies [8].

Here Ca, which is the number of classes outside the package at center that depend upon the classes within this package is equal to 4. Whereas Ce, which is the number of classes inside the package at center that depend upon classes outside this package is 3. Hence I = 3/7.

Thus according to the Stable Dependencies Principle I metric of the package should be greater than the I metric of the packagesit depends upon thereby showing that I metrics decrease in the direction of dependency.

Where do we put the high level design?

We explained the metrics and coupling standards which an ideal system should follow. But after all this there will always remain some software which needs to be changed. These are the high level packages which we described in the sections above. Thus, placing these high level packages are a problem. Should they be in stable packages? This would make the changes very difficult [9].

So only way out would be to use Open/Closed principle. According to this principle, it is possible to create classes that are flexible enough to be extended without modification. Abstract Classes are kind of classes in which specifications can be reused through inheritance but there is no compulsion on its implementation.

References

1. Robert C. Martin
2. Design Principles and Design Patterns by Robert C. Martin
3. OO Design Quality Metrics by Robert Martin
4. Reuse/Release Equivalence Principle
5. Common Closure Principle
6. Common Reuse Principle
7. Acyclic Dependencies Principle
8. Staple Dependencies Principle
9. Stable Abstraction Principle
10. Dependency Inversion Principle
11. Blog Stable Dependencies Principle
12. Object Oriented Design in MultiCore Systems
13. Stability by Robert Martin
14. Package Design