Foundations — SOLID — Liskov Substitution Principle

This page assumes you know nothing. Before you can read SOLID — Liskov Substitution Principle, you must be able to read six little pieces of vocabulary. We build each one from a plain-words meaning, anchor it to a picture, and say exactly why the topic needs it.

0. The scene: a caller, a base, a subclass

Everything in LSP is a three-way story between:

• a base class — a general kind of thing (e.g. Bird),
• a subclass — a more specific version of it (e.g. Penguin),
• a caller — some other code that was written to use the base, and never heard of the subclass.

Why the topic needs these: LSP is entirely about whether a subclass's methods behave like the base's methods. No classes, no methods, no LSP.

1. Inheritance and the extends arrow

Why the topic needs it: LSP is a rule about what inheritance is allowed to do. Without inheritance there is no subclass to substitute.

2. Overriding — replacing a method

Why the topic needs it: every LSP violation on the parent page is an override that misbehaves — Square.setWidth, Penguin.fly. The danger lives in the override.

3. Polymorphism — one call, many bodies

Why this tool and not if-checks? The whole payoff of inheritance is writing code once and trusting all subtypes. If you had to write if (bird is Penguin) ... everywhere, you'd gain nothing. LSP is precisely the condition under which polymorphism is safe. See Polymorphism.

4. The contract: preconditions, postconditions, invariants

A contract is the deal a method offers its caller: "if you give me valid inputs, I promise a valid result." Three words describe it.

Why the topic needs them: the parent's three rules are entirely stated in these words. This whole vocabulary comes from Design by Contract. LSP = "a subclass must not break the base's contract."

5. Reading the symbols $T$, $S$, $\varphi$, and the arrow $⟹$

Now Liskov's formal sentence becomes readable.

So Liskov's line —

$\varphi (x)\text{true for all }x:T⟹\varphi (y)\text{true for all }y:S$

reads in plain words: "Any true fact about base objects must stay true for subclass objects." That's the one-sentence idea, dressed in symbols.

Let $\text{pre}$ and $\text{post}$ be the contract pieces. The parent's two arrows now decode cleanly:

${\text{pre}}_{\text{base}}⟹{\text{pre}}_{\text{sub}}(\text{sub must accept }\ge \text{ base’s inputs})$ ${\text{post}}_{\text{sub}}⟹{\text{post}}_{\text{base}}(\text{sub must promise }\ge \text{ base’s outputs})$

Prerequisite map

Related principles that lean on the same foundations: SOLID — Open Closed Principle (needs polymorphism), SOLID — Interface Segregation Principle (fixes fat contracts), SOLID — Dependency Inversion Principle, SOLID — Single Responsibility Principle.

Equipment checklist