深入解释Liskov替换原则。

Question

深入解释Liskov替换原则。

Accepted Answer

**Liskov替换原则（LSP）**指出，子类型的对象必须能够替代其基类型**而不破坏程序的正确性**。如果代码适用于`Base`，那么它必须适用于任何`Subclass`——相同的行为期望，没有意外。

## 经典违反：Square extends Rectangle

```java
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` *破坏了* 调用者所依赖的契约：独立设置宽度和高度。它通过了"is-a"英文测试，但**违反了LSP**。

## LSP真正的要求

```text
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)
```

这是**输入的逆变，输出的协变**——LSP的形式化核心。

## 如何修复这个例子

放弃继承：`Square`和`Rectangle`都是具有`area()`的`Shape`，但彼此不是。对行为进行建模，而不是天真的分类法。

## 为什么这很重要

LSP是使多态*安全*的关键：没有它，每个`if (x instanceof Square)`检查都会重新出现，打破子类型的意义。

它围绕**行为契约**而不仅仅是术语重新构架了继承设计——"倾向于组合"真正存在的原因是许多is-a关系默默地违反了LSP。