Stable Abstractions Principle

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.

Technorati tags: , , , , ,

Copyright Abhijit Nadgouda.

Discussion [Participate or Link]

  1. OO Design Principles on iface thoughts said:

    […] Stable Abstractions Principle […]

  2. Niclas said:

    “The concrete classes, which are instable, and are expected to change, depend on the concrete classes. ”

    Is this correct?

  3. Abhijit Nadgouda said:

    Thanks for catching in Niclas. It has been corrected. Sometimes I confuse myself more than I should while writing 🙂

  4. Niclas said:

    No problem. I think this is a really good summary on design principles, the best I’ve found online. Thanks for publishing.

    While I’m at it, I think there’s a typo in the entry about Stable Dependencies Principle:

    A package should only depend upon packages that are more stable that it is.

    Should it be “… stable than it is.”?

  5. I can’t believe I get paid for this « I Built His Cage said:

    […] This is endemic of the design of the mess I alluded to in Chaos Crusher. It also flies in the face of conventional (or maybe it’s not) thought on package design: lower-level packages should be more stable than higher-level packages. […]

  6. model Trains said:

    model Trains

    Stable Abstractions Principle | iface thoughts

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.