Liskov substitution

In the last lesson, Checkout worked with any Discount. That only holds if every Discount behaves the way Checkout expects.

A child class can look right and still behave differently. Code that trusts the parent then breaks, far from the child. This lesson shows how to spot that child and how to fix the family.

The problem

A square that is not a rectangle

In maths, every square is a rectangle. So Square extends Rectangle looks correct. stretch is code written for rectangles:

JavaPythonTypeScript

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 {
    @Override void setWidth(int w) { width = w; height = w; }
    @Override void setHeight(int h) { width = h; height = h; }
}

int stretch(Rectangle r) {
    r.setWidth(5);
    r.setHeight(4);
    return r.area(); // the caller expects 5 x 4 = 20
}

stretch(new Rectangle()) returns 20. stretch(new Square()) returns 16, with no error.

The compiler is happy and no test of Square fails. The bug shows up in stretch, which never mentions squares.

Cash that cannot be refunded

The same bug in a food delivery app. Every payment method can pay and refund, and cancelOrder refunds the customer:

JavaPythonTypeScript

interface PaymentMethod {
    void pay(int amount);
    void refund(int amount);
}

class Upi implements PaymentMethod {
    public void pay(int amount) { System.out.println("UPI paid Rs " + amount); }
    public void refund(int amount) { System.out.println("UPI refunded Rs " + amount); }
}

class CashOnDelivery implements PaymentMethod {
    public void pay(int amount) { System.out.println("Cash collected Rs " + amount); }
    public void refund(int amount) {
        throw new UnsupportedOperationException("no online refund for cash");
    }
}

void cancelOrder(PaymentMethod method, int amount) {
    method.refund(amount);
    System.out.println("Order cancelled");
}

• cancelOrder(new Upi(), 400) prints UPI refunded Rs 400, then Order cancelled.
• cancelOrder(new CashOnDelivery(), 400) crashes before the order is cancelled. Java throws UnsupportedOperationException, Python NotImplementedError, TypeScript an Error.

cancelOrder trusted the interface: every PaymentMethod can refund. One child broke that promise.

The idea

Code that works with a parent must keep working, unchanged, when you pass it any child.

Barbara Liskov stated this rule in a 1987 talk, so it carries her name. "Is a" in real life is not enough. The child must also behave like the parent, for every caller.

Three promises a child must keep

1. Accept. A music app's Speaker takes any volume from 0 to 100. A CarSpeaker child that throws above 50 breaks a caller that sets 80.
2. Return. Rectangle.setWidth promises that only the width changes. Square changes the height too, so stretch gets 16.
3. No surprises. PaymentMethod.refund never said it might fail. CashOnDelivery throws anyway, and the caller has no catch for it.

The fix is in the family tree

You do not patch the caller. You redesign the hierarchy, so each parent promises only what all its children can do:

┌───────────────────────────────────────────────────┐
│                                                   │
│          ┌───────────────────────┐                │
│          │ <<interface>>         │                │
│          │ PaymentMethod         │                │
│          ├───────────────────────┤                │
│          │ + pay(amount)         │                │
│          └───────────────────────┘                │
│             △                 △                   │
│             ╎                 │                   │
│   ┌─────────┴───────┐ ┌───────┴───────────────┐   │
│   │ CashOnDelivery  │ │ <<interface>>         │   │
│   └─────────────────┘ │ RefundablePayment     │   │
│                       ├───────────────────────┤   │
│                       │ + refund(amount)      │   │
│                       └───────────────────────┘   │
│                                 △                 │
│                                 ╎                 │
│                       ┌─────────┴─────────────┐   │
│                       │ Upi                   │   │
│                       └───────────────────────┘   │
│    ──▷ extends   ╌╌▷ implements                   │
│                                                   │
└───────────────────────────────────────────────────┘

• PaymentMethod promises only what every method can do: pay.
• RefundablePayment extends it with refund, for methods that can really refund.
• Upi implements RefundablePayment. CashOnDelivery implements only PaymentMethod.
• cancelOrder asks for a RefundablePayment, so cash can never reach it.

The fix

Shapes: share only what is true for both

A square and a rectangle both have an area. They do not resize the same way. So the shared parent offers only area(), and neither class has setters.

JavaPythonTypeScript

interface Shape {
    int area();
}

record Rectangle(int width, int height) implements Shape {
    public int area() { return width * height; }
}

record Square(int side) implements Shape {
    public int area() { return side * side; }
}

Rectangle(5, 4) has area 20 and Square(4) has area 16. Any code that takes a Shape gets exactly what area() promises. To resize, you create a new shape.

Payments: split the promise

JavaPythonTypeScript

interface PaymentMethod {
    void pay(int amount);
}

interface RefundablePayment extends PaymentMethod {
    void refund(int amount);
}

class Upi implements RefundablePayment {
    public void pay(int amount) { System.out.println("UPI paid Rs " + amount); }
    public void refund(int amount) { System.out.println("UPI refunded Rs " + amount); }
}

class CashOnDelivery implements PaymentMethod {
    public void pay(int amount) { System.out.println("Cash collected Rs " + amount); }
}

void cancelOrder(RefundablePayment method, int amount) {
    method.refund(amount);
    System.out.println("Order cancelled");
}

• Both classes still pay: a list of PaymentMethod can hold a Upi and a CashOnDelivery.
• cancelOrder(new CashOnDelivery(), 400) now fails to compile in Java and TypeScript, because CashOnDelivery has no refund.
• In Python, a type checker such as mypy reports the same call as an error before the code runs.

The crash moved from a customer's phone to your editor. Cash orders take their own path: nothing was charged online, so there is nothing to refund online.

How it runs

1. The orders page asks cancelOrder to cancel a UPI order.
2. cancelOrder calls refund without checking the class. Every RefundablePayment keeps that promise.
3. A card class added next month slots in with no change to cancelOrder. That is open-closed, and it only works because of Liskov.

When to use it

Signals in the code

• A child overrides a method to throw "not supported", or to do nothing.
• Callers check the type first: instanceof in Java, isinstance in Python, before they call a method.
• "Is a" holds in real life, but the behaviour differs: a square and a rectangle, a penguin and a bird that flies.
• The parent's tests fail on the child. Run every test written for the parent with each child. A failure means a broken promise.

When it is too much

Do not split a hierarchy for a difference no caller can see. A child that logs more, or runs faster, keeps every promise. Split only when a caller would get a wrong answer or a crash.

Liskov or interface segregation?

The two meet often. CashOnDelivery broke a promise because PaymentMethod asked for a method cash cannot do.

Read more

• Liskov substitution principle on Wikipedia, with its history and the formal rules
• A behavioral notion of subtyping by Barbara Liskov and Jeannette Wing, 1994, the original paper
• List in the Java 21 docs: see "Unmodifiable Lists"
• The ReadonlyArray type in the TypeScript handbook

Next: interface segregation. Small, focused interfaces like PaymentMethod and RefundablePayment, so no class has to fake a method it cannot do.