The Liskov Substitution Principle (LSP) states that objects of a subtype must be substitutable for their base type without breaking the program's correctness. If code works with a Base, it must work with any Subclass — same behavioral expectations, no surprises.
class Rectangle {
protected int w, h;
void setWidth(int w) { this.w = w; }
void setHeight(int h) { this.h = h; }
int area() { return w * h; }
}
class Square extends Rectangle { // "a square IS-A rectangle"... seemingly
void setWidth(int w) { this.w = w; this.h = w; } // keep sides equal
void setHeight(int h) { this.w = h; this.h = h; }
}
void resize(Rectangle r) {
r.setWidth(5);
r.setHeight(4);
assert r.area() == 20; // holds for Rectangle... FAILS for Square (area=16)
}
Square breaks the contract callers rely on: setting width and height independently. It passes the "is-a" English test but violates LSP.
A subtype must NOT:
✗ strengthen preconditions (demand more than the base, e.g. reject valid inputs)
✗ weaken postconditions (promise less than the base)
✗ break invariants the base guarantees
✗ throw new unexpected exceptions for previously valid calls
A subtype MAY:
✓ weaken preconditions (accept more) ✓ strengthen postconditions (promise more)
This is contravariance of inputs, covariance of outputs — the formal core of LSP.
Drop the inheritance: Square and Rectangle are both Shapes with an area(), but neither is the other. Model behavior, not naive taxonomy.
LSP is what makes polymorphism safe: without it, every if (x instanceof Square) check creeps back in, defeating the point of subtyping.
It reframes inheritance design around behavioral contracts, not vocabulary — the real reason "favor composition" exists is that many is-a relationships silently violate LSP.