Liskov Substitution Principle

Description

The Liskov Substitution Principle says that an object of a subtype must work anywhere its supertype is expected, without surprising the code that uses it. It's what makes polymorphism trustworthy: if every implementation keeps the parent's promises, callers never need to check which one they got. This skill covers what those promises are, the classic ways subclasses break them, and how to model types so they don't.

Here's the classic example of breaking it:

class Rectangle {
    protected int width, height;
    void setWidth(int w)  { width = w; }
    void setHeight(int h) { height = h; }
    int area() { return width * height; }
}

class Square extends Rectangle {          // "a square IS a rectangle", right?
    void setWidth(int w)  { width = w; height = w; }
    void setHeight(int h) { width = h; height = h; }
}

void stretch(Rectangle r) {
    r.setWidth(5);
    r.setHeight(4);
    assert r.area() == 20;                // fails for a Square: area is 16
}

class Rectangle:
    def __init__(self):
        self.width = self.height = 0

    def set_width(self, w: int) -> None:
        self.width = w

    def set_height(self, h: int) -> None:
        self.height = h

    def area(self) -> int:
        return self.width * self.height


class Square(Rectangle):                  # "a square IS a rectangle", right?
    def set_width(self, w: int) -> None:
        self.width = self.height = w

    def set_height(self, h: int) -> None:
        self.width = self.height = h


def stretch(r: Rectangle) -> None:
    r.set_width(5)
    r.set_height(4)
    assert r.area() == 20                 # fails for a Square: area is 16

Mathematically a square is a rectangle. In code, Square breaks a promise every Rectangle user relies on: setting the width doesn't change the height.

We'll go from simple to more technical:

1. The principle: behavior, not just method signatures.
2. The contract rules: preconditions, postconditions, invariants, exceptions.
3. How to check a hierarchy and fix it, step by step.
4. Where substitution fails in real libraries.

The principle

Objects of a subtype must be usable anywhere the supertype is expected, without breaking the program.

Subtyping is about behavior, not just method signatures. A subclass must keep the parent's contract:

• It may not demand more from callers (no stronger preconditions: rejecting inputs the parent accepted).
• It may not promise less (no weaker postconditions: returning results the parent ruled out).
• It must preserve the parent's invariants (width and height are independent).
• It shouldn't throw new kinds of exceptions callers can't expect.

How to apply it, step by step

1. Write down what callers of the parent can rely on (the contract) - ideally as tests.
2. For each subclass, check it keeps every one of those promises.
3. If a subclass can't (a Penguin that can't fly(), a Square that can't resize freely), the hierarchy is wrong.
4. Fix the model: split capabilities into separate interfaces, use composition, or make the types immutable (an immutable Square never has to fake being resized).
5. Run the same contract tests against every implementation.

Where you'll see it

• List implementations: ArrayList and LinkedList differ in speed but behave identically - you can swap them freely. (Python: list, tuple and range are all collections.abc.Sequences.)
• Collections.unmodifiableList throws on add() - a well-known, documented compromise in the JDK's collection design. Python's collections.abc avoids it by splitting the roles: tuple is a Sequence but not a MutableSequence, so it simply has no append to refuse.
• Any plugin or strategy interface: every implementation must behave the way the calling code expects.

Which tool for which job?

Common mistakes

Check yourself

Try to answer before opening each one - recalling beats re-reading.

1. A ReadOnlyList extends ArrayList throws on add(). Why is that an LSP problem?

2. How does making Rectangle and Square immutable avoid the classic violation?

3. Can a subclass accept a wider range of inputs than its parent?

Key takeaways

• A subtype must keep every promise its supertype makes - behavior, not just signatures.
• No stronger preconditions, no weaker postconditions, preserved invariants.
• UnsupportedOperationException overrides and instanceof checks in callers are red flags.
• Fix with separate capabilities, composition or immutability - and contract tests.