So far we have discussed The Acyclic Dependency Principle and Stable Dependencies Principle, in this post we will go through Stable Abstractions Principle

A component should be as abstract as it is stable.

Robert Martin

High level architecture/policies are part of software and they should be present in a component that is stable, because we don’t want them to change often. However, if we put these high level policies into a stable component, then the code representing these policies would be difficult to change. And that could make the overall architecture inflexible. 

So where should we put these policies so that they are stable as well as flexible. The answer is Open Closed Principle. This principle as we have seen gives us the opportunity to have classes that can be easily extended without modification using Abstract classes.

We can see that SAP creates a relationship between stability and abstractions. It says that a stable component should also be abstract so that it’s stability does not prevent it from being extended. So, for a component to be stable, it should contain interfaces and abstract classes.

SAP + SDP = DIP for components

SDP says dependencies should run in the direction of stability. SAP says stability implies abstraction . So dependencies run in the direction of abstraction. 

Measuring Abstraction 

Abstractions A = Na / Nc

where Na -> number of abstract classes and interfaces in the component

Nc -> number of classes in the component

A ranges between 0 and 1, 0 means component has no abstractions, 1 means, component has only abstract classes and interfaces.

The Main Sequence

Components on (0, 1) are maximally stable and abstract. Components at (1, 0) are maximally unstable and concrete. Other components lie on the line between these two components depending on the degree of stability and abstraction.

The Zone of Pain 

Component on (0, 0) is highly stable and concrete. It is rigid. It cannot be extended as it’s not abstract, It is difficult to change because of its high stability. The area around (0, 0) is called zone of pain.

There are few components that lie in this area. Example – Database schema. These are volatile and concrete and many components depend on them. 

Non volatile components are harmless in this zone as they don’t change. Only the volatile components cause pain like database schema mentioned above. 

The Zone of Uselessness

Component at (1, 1) is maximally abstract and has no dependents. These components are useless and so the zone is called zone of uselessness.

These are generally dead code often leftover from abstract classes that never were implemented. 

Main Sequence

Components that lie on this line are not “too abstract” or “too stable”. It is depended on to the extent that it is abstract and it depends on others to the extent it is concrete. As good architects, we should try to place our components on this line.

Distance from the main sequence

Distance or D = | A + I  -1 |, range is between (0, 1). 0 indicates component is on main sequence, 1 indicates it is far from main sequence.

Using this metric, design can be analyzed for its overall conformance to main sequence. We can calculate D metric fir each component. Then based on its value, component can be evaluated and changed.

Thanks for stopping by! Hope this gives you a brief overview in to Stable Abstractions Principle. Eager to hear your thoughts and chat, please leave comments below and we can discuss.