Het Liskov Substitution Principle (LSP) stelt dat objecten van een subtype vervangbaar moeten zijn voor hun basistype zonder de juistheid van het programma in gevaar te brengen. Als code werkt met een Base, moet het werken met elke Subclass — dezelfde gedragsverwachtingen, geen verrassingen.
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 breekt het contract warop aanroepers rekenen: width en height onafhankelijk instellen. Het doorstaat de "is-a" Engelse test, maar schendt 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)
Dit is contravariantie van invoer, covariantie van uitvoer — de formele kern van LSP.
De inheritance laten vallen: Square en Rectangle zijn beide Shapes met een area(), maar geen van beide is de ander. Modelleer gedrag, niet naïeve taxonomie.
LSP is wat polymorfisme veilig maakt: zonder het kruipt elke if (x instanceof Square) check terug, wat het punt van subtypering tenietdoet.
Het herdefineert inheritance-ontwerp rond gedragscontracten, niet vocabulaire — de echte reden dat "favor composition" bestaat is dat veel is-a-relaties stilzwijgend LSP schenden.