Skip to content

Liskov Substitution Principle

Certify that a subtype can safely replace its supertype only when it honours the supertype's full contract toward clients — weakening preconditions, strengthening postconditions, preserving invariants — regardless of taxonomy or compilability.

Core Idea

The Liskov Substitution Principle states the condition under which a subtype can correctly replace its supertype: substituting an instance of subtype S for supertype T must leave any client written against T's interface unchanged. The behavioural conditions are precise — preconditions may be weakened but not strengthened, postconditions strengthened but not weakened, invariants preserved, and exceptions not surprising the client. It separates syntactic subtyping, taxonomic is-a, and behavioural subtyping.

Scope of Application

LSP lives within typed object-oriented software, across the design and tooling practices that govern a nominal type hierarchy with client code written against a supertype's contract.

  • OO design and type systems — the foundational constraint on inheritance, the L of SOLID.
  • Design-by-contract programming — Eiffel formalising pre/post/invariant conditions.
  • Static analysis and formal verification — variance analysis, refinement types, JML.
  • Refactoring practice — "favor composition over inheritance" targeting LSP failures.
  • API and library design — documenting the contract subclassable types impose.

Clarity

LSP separates three notions OO design collapses: syntactic subtyping (has the methods), taxonomic is-a (a square is a rectangle), and behavioural subtyping (honours the contract) — the only one it cares about. It also reclassifies a broken hierarchy from a style problem into a type-system bug the compiler cannot catch, changing the remedy from cosmetic to structural.

Manages Complexity

An open-ended judgement pulling in both types' semantics and every client collapses into four mechanically checkable variance conditions at the interface. Satisfy all four and substitution is sound across every client at once; violate any and it is unsound — the verdict reads off the check. The remedy space contracts to a small structural menu.

Abstract Reasoning

The principle licenses a four-condition variance check deciding substitutability without simulating clients, a three-way disambiguation isolating behavioural subtyping, a reclassification of a violation as a type-system bug (fixing the remedy branch), and an interventionist design-time move predicting client fragility before it manifests.

Knowledge Transfer

Within typed OO software LSP transfers literally as mechanism across design, contracts, verification, refactoring, and API design, the whole apparatus carrying untranslated. Beyond typed software the portable skeleton — a specialization may stand in only if it honours the generalization's contract to clients — recurs in contract novation, ecological function replacement, and role substitution, but that belongs to a general behavioral-substitutability pattern, each substrate supplying its own enforcement.

Relationships to Other Abstractions

Local relationship map for Liskov Substitution PrincipleParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Liskov SubstitutionPrincipleDOMAINPrime abstraction: Substitutability — is a decomposition ofSubstitutabilityPRIMEDomain-specific abstraction: Refused Bequest — presupposesRefused BequestDOMAIN

Current abstraction Liskov Substitution Principle Domain-specific

Parents (1) — more general patterns this builds on

  • Liskov Substitution Principle is a decomposition of Substitutability Prime

    LSP is behavioral substitutability specialized to typed inheritance and made checkable through contract variance rules.

Children (1) — more specific cases that build on this

  • Refused Bequest Domain-specific presupposes Liskov Substitution Principle

    Refused Bequest presupposes LSP because the smell is precisely a subclass refusing inherited obligations that substitutability requires it to honor.

Hierarchy paths (8) — routes to 4 parentless roots

Neighborhood in Abstraction Space

Liskov Substitution Principle sits in a moderately populated region (44th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Unclustered & Miscellaneous (309 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12