Le Principe de Substitution de Liskov (LSP) stipule que les objets d'un sous-type doivent être substituables à leur type de base sans briser la correction du programme. Si le code fonctionne avec une Base, il doit fonctionner avec n'importe quelle Subclass — mêmes attentes comportementales, aucune surprise.
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 rompt le contrat sur lequel les appelants comptent : définir la largeur et la hauteur indépendamment. Il passe le test anglais « is-a » mais viole le 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)
C'est la contravariance des entrées, la covariance des sorties — le cœur formel du LSP.
Abandonner l'héritage : Square et Rectangle sont tous les deux des Shapes avec une area(), mais ni l'un ni l'autre n'est l'autre. Modélisez le comportement, pas la taxonomie naïve.
Le LSP est ce qui rend le polymorphisme sûr : sans lui, chaque contrôle if (x instanceof Square) réapparaît insidieusement, anéantissant l'intérêt de la sous-typage.
Il reconfiguralise la conception de l'héritage autour de contrats comportementaux, non de vocabulaire — la véritable raison pour laquelle « favoriser la composition » existe est que nombreuses relations is-a violent silencieusement le LSP.