Parimin e Zëvendësimit të Liskov-it (LSP) thotë se objektet e një nëntipi duhet të jenë zëvendësuese për llojin e tyre bazë pa e thyer korrektësinë e programit. Nëse kodi funksionon me një Base, duhet të funksionojë me çfarëdo Subclass — pritshmëri të njëjta të sjelljes, pa befasi.
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 thyen kontratën që mbështetësin e shikojnë: vendosja e gjerësisë dhe lartësisë në mënyrë të pavarur. Kalon testin e anglishtes "is-a", por shkel 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)
Ky është kontravarianca e hyrjeve, kovarianca e daljeve — bërthama formale e LSP-së.
Lidhuni dediminkën: Square dhe Rectangle janë të dyja Shape-a me një area(), por asnjëra nuk është tjetra. Modeloni sjelljem, jo taksonomi naive.
LSP është ajo që e bën polimorfizmin të sigurt: pa të, çdo kontroll if (x instanceof Square) rrëshqet mbrapa, duke disfunksionalizuar qëllimin e nënshtrimit.
Ri-kuadron dizajnin e dediminke rreth kontratave të sjelljes, jo përkatësisht — arsyeja e vërtetë që "favorizon përbërje" ekziston është se shumë marrëdhënie is-a në heshtje shkellin LSP-në.