O Liskov Substitution Principle (LSP) afirma que objetos de um subtipo devem ser substituíveis por seu tipo base sem quebrar a corretude do programa. Se o código funciona com uma Base, deve funcionar com qualquer Subclass — mesmas expectativas comportamentais, sem surpresas.
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 quebra o contrato em que os chamadores confiam: definir largura e altura independentemente. Passa no teste "is-a" em inglês, mas 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)
Este é contravariance de entradas, covariance de saídas — o núcleo formal do LSP.
Abandonar a herança: Square e Rectangle são ambos Shapes com um area(), mas nenhum é o outro. Modele comportamento, não taxonomia ingênua.
LSP é o que torna o polimorfismo seguro: sem ele, cada verificação if (x instanceof Square) volta a aparecer, derrotando o objetivo da subtipagem.
Remodeliza o design de herança em torno de contratos comportamentais, não vocabulário — o verdadeiro motivo para "favorecer composição" é que muitos relacionamentos is-a silenciosamente violam LSP.