Il Liskov Substitution Principle (LSP) stabilisce che gli oggetti di un sottotipo devono essere sostituibili al loro tipo di base senza infrangere la correttezza del programma. Se il codice funziona con una Base, deve funzionare con qualsiasi Subclass — stesse aspettative comportamentali, nessuna sorpresa.
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 infrange il contratto su cui i chiamanti si affidano: impostare larghezza e altezza indipendentemente. Passa il test "is-a" in inglese ma viola 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)
Questa è la contravarianza degli input, covarianza degli output — il nucleo formale di LSP.
Abbandonare l'eredità: Square e Rectangle sono entrambi Shape con un area(), ma nessuno è l'altro. Modellare il comportamento, non la tassonomia ingenua.
LSP è ciò che rende il polimorfismo sicuro: senza di esso, ogni controllo if (x instanceof Square) si insinua di nuovo, vanificando il punto del subtipe.
Ridefinialisca la progettazione dell'eredità attorno ai contratti comportamentali, non al vocabolario — la vera ragione per cui "favorire la composizione" esiste è che molte relazioni is-a violano silenziosamente LSP.