Das Liskov-Substitutions-Prinzip (LSP) besagt, dass Objekte eines Subtyps für ihren Basistyp einsetzbar sein müssen, ohne die Korrektheit des Programms zu beeinträchtigen. Wenn Code mit einer Base funktioniert, muss er mit jeder Subclass funktionieren — gleiche Verhaltenserwartungen, keine Überraschungen.
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 bricht den Vertrag, auf den sich Aufrufer verlassen: das unabhängige Setzen von Breite und Höhe. Es besteht den "is-a"-Test in Englisch, verletzt aber 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)
Dies ist Kontravarianz der Eingaben, Kovarianz der Ausgaben — der formale Kern von LSP.
Verzichten Sie auf die Vererbung: Square und Rectangle sind beide Shapes mit einer area(), aber keines ist das andere. Modellieren Sie Verhalten, keine naive Taxonomie.
LSP macht Polymorphismus sicher: ohne es schleichen sich immer wieder if (x instanceof Square)-Checks ein, was den Sinn von Subtyping zunichte macht.
Es rahmt die Vererbungsgestaltung um Verhaltensverträge ein, nicht um Vokabeln — der wirkliche Grund, dass "Komposition bevorzugen" existiert, ist, dass viele is-a-Beziehungen stillschweigend LSP verletzen.