There is a principle in software called the “Stable Dependency Principle” which states:

Dependencies between released components must run in the direction of stability. The dependee must be more stable than the depender.

Which is of course what we all want when developing software. We never want anything we depend on to change its API, because that means we have to “unnecessarily” change our code too. (But if we have an API that we manage, we should be able to change it any time we darn well please.)

We measure the instability of a class by the number of classes that depend on it (C[a]) and the number of classes that it depends on (C[e]):

I = C[e] / (C[a] + C[e])

So the range of I is 0 <= I <= 1, where a value of 0 means that the class is completely stable (since nothing depends on it) and a value of 1 means, well, you can change your code whenever your heart desires. With I defined, we can restate the Stable Dependency Principle in terms of it:

Components should be arranged such that components with high I metrics should depend upon components with low I metrics.

which again basically means that instable components should depend on stable components. This leads us to a design principle to make use of this favorable dependency flow. This is called the “Stable Abstraction Principle”:

The more stable a component is, the more it must consist of abstract classes. A completely stable component should consist of nothing but abstract classes.

Of course in Java and .NET, you would replace “abstract class” with “interface”, but you get the picture. So basically the more interfaces you have, the more stable your component is (assuming of course your dependers are using your interfaces rather than some internal implementation that’s public). Let’s look at how you calculate the abstraction of a component:

A = (# of interfaces) / (# of classes and interfaces)

For example if your component has 2 interfaces and 3 classes, your component’s A value would be 2/5 or 0.4. As with I, the range of A is 0 <= A <= 1, with a value of 0 meaning you have no interfaces and 1 meaning it’s nothing but interfaces.

Calculating both I and A for your component will put you somewhere on this graph:

At the four extremes you have maximally stable and abstract components, maximally instable and concrete components, maximally stable and concrete components, and maximally instable and abstract components. Most components fall somewhere in between. What we want though is for our components to be somewhere along the main sequence with some stable interfaces and some changing concrete classes. Staying on the main sequence ensures that the more abstract your component is the more stable it will be. We measure the distance of the component from the main sequence like so:

D = |(A + I - 1) / sqrt(2) |

You want D to be as close to 0 as possible to make sure your component is on the main sequence, although values of up to about 0.707 are usually ok. But desirably, keep it close to 0.

So what do you think? Does a bad combination of A and I values necessarily mean your code is bad? I know that after learning about this, I’ve started to think about the abstractness and instability in my designs a little more. I’ll make a rough estimation of I and A in my components and see where I end up. At the the very least, it’s made think about using more interfaces and using them better, and that’s nothing but good.