SAP

Stable Abstractions Principle

“A component should be as abstract as it is stable.” – Robert C. Martin

  • Stable components should be abstract (interfaces/abstract classes) so they can be extended without modification.
  • Unstable components should be concrete (implementations) because they are easy to change.

When to use

When designing the core relationships of your architecture.

Why it matters

  • Flexibility: If a stable component is concrete (full of code), you can’t extend it. If it’s abstract, you can extend it to add features without changing the stable source (OCP).

Signs of Violation

  • A weirdly “Stable” component (lots of dependents) that is also constantly changing its code logic (concrete).
  • An Abstract component that nobody uses.

Explanation

Problem

You want high stability (lots of dependents) but also high flexibility (easy to extend). Code is rigid. Abstractions are flexible.

Solution

The more others depend on you (Stability), the more abstract you should be (Interfaces).

Real world analogy

The electric socket standard is extremely stable (everyone uses it) and extremely abstract (it defines holes and voltage, not how the electricity is made). Wall sockets don’t contain diesel generators.

Pros and Cons

Pros Cons
  • Maximum OCP
  • Flexible architecture
    		•
  • Over-abstraction if applied to simple CRUD apps
    		•

    Comparison

    • SDP: SAP + SDP = “Depend on Abstractions” (DIP) applied to components.

    Code example

    Typescript

    Bad (Violation)

    Good (Adherence)

    PHP

    Bad (Violation)

    Good (Adherence)