A Liskov-helyettesítési elv (LSP) kimondja, hogy az altípus objektumainak helyettesíthetőnek kell lenniük az alapszintükön anélkül, hogy a program helyességét megtörné. Ha a kód működik egy Base osztályhoz, akkor működnie kell minden Subclass osztályhoz — ugyanolyan viselkedési elvárások, nincs meglepetés.
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)
}
A Square megtöri azt az szerződést, amelyre a hívók számítanak: a szélesség és magasság függetlenül történő beállítása. Megfelel az angol "is-a" tesztnek, de megsértik az LSP-t.
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)
Ez a bemenetek kontravariációja, kimenetek kovariációja — az LSP formális magja.
Hagyja el az öröklődést: a Square és a Rectangle mindkettő Shape area() metódussal, de egyik sem a másik. A viselkedést modellezze, nem a naiv taxonómiát.
Az LSP az, amely a polimorfizmust biztonságossá teszi: nélküle minden if (x instanceof Square) ellenőrzés visszacsúszik, megtagadva az altípusosítás értelmet.
Az öröklödési tervezést viselkedési szerződések köré alakítja át, nem a szókincs — az igazi oka annak, hogy "kedveljük a kompozíciót" az, hogy sok "is-a" kapcsolat csendesen megsértik az LSP-t.