Liskovin substituutio-periaate (LSP) määrää, että alatyyppin objektit on voitava korvata niiden perustyypillä ilman ohjelman oikeellisuuden rikkoontumista. Jos koodi toimii Base-tyypin kanssa, sen on toimittava minkä tahansa Subclass-tyypin kanssa — samat käyttäytymisen odotukset, ei yllätyksiä.
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 rikkoo sopimuksen, johon kutsujat luottavat: leveyttä ja korkeutta ei voi asettaa riippumattomasti. Se läpäisee "on-a" -testin englanniksi, mutta rikkoo LSP:n.
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)
Tämä on tulojen kontravarianssia ja tulosten kovarianssia — LSP:n muodollinen ydin.
Hylkää perintö: Square ja Rectangle ovat molemmat Shape-tyyppisiä, joilla on area(), mutta kumpainen ei ole toinen. Mallinna käyttäytymistä, ei naivia taksonomia.
LSP tekee polymorfismista turvallista: ilman sitä jokainen if (x instanceof Square) -tarkistus palaa takaisin, mitätöiden alisäätämisen tarkoituksen.
Se muotoilee uudelleen periytymisen suunnittelun käyttäytymisen sopimusten ympärille, ei sanastoon — oikea syy "suosi kompositiota" -neuvoon on se, että monet on-a-suhteet rikkovaat LSP:n hiljaisesti.