El Principio de Sustitución de Liskov (LSP) establece que los objetos de un subtipo deben ser sustituibles por su tipo base sin romper la corrección del programa. Si el código funciona con una Base, debe funcionar con cualquier Subclass — mismas expectativas de comportamiento, sin sorpresas.
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 rompe el contrato en el que los llamadores confían: establecer ancho y alto de forma independiente. Pasa la prueba del inglés "is-a" pero viola 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)
Esto es contravarianza de entradas, covarianza de salidas — el núcleo formal de LSP.
Abandonar la herencia: Square y Rectangle son ambas Shapes con un area(), pero ninguna es la otra. Modelar comportamiento, no taxonomía ingenua.
LSP es lo que hace que el polimorfismo sea seguro: sin él, cada verificación if (x instanceof Square) vuelve a aparecer, anulando el propósito de la subtipificación.
Re-encuadra el diseño de herencia alrededor de contratos de comportamiento, no vocabulario — la razón real por la que "favorecer composición" existe es que muchas relaciones is-a violan silenciosamente LSP.