Liskov Substitution Principle (LSP) fastslår, at objekter af en undertype skal kunne substitueres for deres basistype uden at bryde programmets korrekthed. Hvis kode fungerer med en Base, skal den fungere med enhver Subclass — samme adfærdsmæssige forventninger, ingen overraskelser.
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 bryder kontrakten, som kalderen stoler på: indstilling af bredde og højde uafhængigt. Det består "is-a" sprogtesten, men overtræder 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)
Dette er kontravarians af inputs, kovarians af outputs — det formelle hjerte af LSP.
Drop arven: Square og Rectangle er begge Shapes med en area(), men ingen er den anden. Model adfærd, ikke naiv taksonomi.
LSP er det, der gør polymorfi sikker: uden den sniksner alle if (x instanceof Square) kontroller tilbage ind, hvilket besejrer hele pointen med subtypning.
Det omformulerer arvdesign omkring adfærdsmæssige kontrakter, ikke ordforråd — den virkelige grund til, at "favoriser komposition" findes, er, at mange is-a relationer stiltiende overtræder LSP.