Liskov-Substitution

The Liskov Substitution Principle is the one that makes polymorphism safe. Named after Barbara Liskov, it says: objects of a subtype must be usable anywhere the base type is expected, without breaking the program's correctness. If code works with a FeePolicy, it must work with every FeePolicy - no exceptions, no "but this one throws if you call it wrong." Violate LSP and Open/Closed collapses, because you can no longer trust the abstraction.

Substitutability, not just "is-a"

Inheritance in Java gives you "is-a": a Square is a Rectangle, a PenguinAccount is an Account. But LSP demands more than the type checker's approval - it demands behavioral compatibility. The subtype must honor the contract the base type promised: same or weaker preconditions, same or stronger postconditions, no surprising exceptions, no strengthened requirements.

The famous counterexample is the square/rectangle:

class Rectangle {
    protected int width, height;
    void setWidth(int w)  { this.width = w; }
    void setHeight(int h) { this.height = h; }
    int area() { return width * height; }
}
class Square extends Rectangle {          // a square IS-A rectangle, right?
    void setWidth(int w)  { this.width = w; this.height = w; }   // keep it square
    void setHeight(int h) { this.width = h; this.height = h; }
}

Now this perfectly reasonable code, written against Rectangle, breaks:

void resizeAndCheck(Rectangle r) {
    r.setWidth(5);
    r.setHeight(4);
    assert r.area() == 20;   // holds for Rectangle... FAILS for Square (area == 16)
}

Square passes the compiler but violates the behavioral contract: Rectangle promised width and height are independent, and Square broke that promise. Any code relying on the base type's contract is now unsafe. "Is-a" was true; substitutable was not.

Tells of an LSP violation

You've probably smelled these without naming them:

• A subtype throwing on an inherited method - UnsupportedOperationException in an override (the classic List.of(...) immutable list that throws on add).
• instanceof checks before using a subtype - code that must ask "which subclass is this?" is admitting the subtypes aren't truly substitutable.
• Overrides that do nothing or weaken behavior - an override that silently ignores a call the base type honored.
• Strengthened preconditions - a subtype that rejects inputs the base type accepted.

In ledger-legacy, a ReadOnlyAccount extends Account that throws on deposit() is an LSP landmine: any method taking an Account and calling deposit will blow up on that one subtype.

Fixing it: model the real relationship

The fix is rarely "make the subtype behave" - it's usually that inheritance was the wrong tool. A square and a rectangle are both shapes with an area(), but neither is a safe subtype of the other under mutation. Prefer:

• Composition over inheritance - Square has dimensions, it isn't a mutable Rectangle.
• A common abstraction - both implement a Shape interface with area(), neither extends the other.
• Immutability - if Rectangle were immutable (no setters), Square could safely extend it, because the broken promise was about mutation.