Stable Abstractions Principle (SAP) can be considered to be a corollary of the Stable Dependencies Principle (SDP), which said that packages should depend only on more stable packages. The stability metrics showed that packages were instable if its classes depended on classes in another package.
Applying the class design principles, especially the Dependency Inversion Principle (DIP), flexibility is built into a design by introducing abstract classes. Concrete classes depend on the abstract classes for reusability and extensibility. This directly drives that
Packages that are maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should be in proportion to its stability.
An abstract class tends to be more stable, as it does not depend on concrete classes. The concrete classes, which are instable, and are expected to change, depend on the
concrete abstract classes. This ultimately means, that dependencies in packages are in the direction of abstraction.
From another perspective, abstraction is used to contain high-level design, which is used to hold the concept. Objects of concepts don’t exist in nature, and rightly so abstract classes cannot be instantiated. The concrete classes which depend on the abstractions are instantiated and can be modelled after the real world objects. As time goes by, the real world objects change more frequently than the concept itself. This leads us to a corollary that abstraction brings stability.
Robert Martin (pdf) does a mathematical explanation of the measurement of abstractness of a package. Based on this, he discusses implications of the metrics on certain examples like database schemas and an utility library and marks the zone of exclusion.
Back to Design Principles.
Copyright Abhijit Nadgouda.