OOP里氏替换原则实例详解

**OOP里氏替换原则应用实例解析：保证程序正确性的关键** 里氏替换原则（LSP）是面向对象编程中的重要设计原则，强调子类必须能够替换其父类，且不影响程序的正确性。本文通过图形面积计算的实例，深入剖析了违反LSP的常见情况，即Square继承Rectangle导致行为不一致的问题。通过对比违反LSP和遵循LSP的设计方案，展示了如何通过合理的继承关系和抽象类（Shape）的应用，确保子类行为与父类契约保持一致。最终，Rectangle和Square各自独立实现getArea方法，避免了程序逻辑错误，符合LSP。本文旨在帮助开发者理解LSP的实际应用，避免因不合理的继承关系导致bug，提升代码的可维护性和扩展性。

里氏替换原则要求子类能替换父类且不改变程序正确性，文中以图形面积计算为例，指出Square继承Rectangle会导致行为不一致，违反LSP；改进方案是让Rectangle和Square均继承自抽象类Shape，各自独立实现getArea方法，确保行为契约一致，从而符合LSP。

里氏替换原则（Liskov Substitution Principle, LSP）是面向对象设计中的重要原则之一，强调子类应该能够替换其父类出现在程序中的任何地方，并且不改变程序的正确性。这意味着子类不仅要继承父类的方法和属性，更要保持行为的一致性。下面通过一个实际例子来说明该原则的应用。

场景：图形面积计算

假设我们正在开发一个图形处理系统，需要计算不同图形的面积。定义一个基类 Shape，并让具体的图形如矩形、正方形继承它。

违反LSP的例子：

定义一个 Rectangle 类：

class Rectangle {
    protected int width, height;
<pre class="brush:java;toolbar:false;">public void setWidth(int width) {
    this.width = width;
}

public void setHeight(int height) {
    this.height = height;
}

public int getArea() {
    return width * height;
}

}

然后创建一个 Square 类继承 Rectangle，因为正方形是一种特殊的矩形：

class Square extends Rectangle {
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width);
    }
<pre class="brush:java;toolbar:false;">public void setHeight(int height) {
    super.setHeight(height);
    super.setWidth(height);
}

}

问题出现在以下使用场景：

public static void testRectangle(Rectangle r) {
    r.setWidth(5);
    r.setHeight(4);
    if (r.getArea() != 20)
        System.out.println("面积计算错误！");
}

这个方法对普通 Rectangle 没问题，但传入 Square 实例时：

• 调用 setWidth(5)，内部将宽高都设为5
• 再调用 setHeight(4)，又将宽高都设为4
• 最终面积是16，而不是预期的20

尽管语法上 Square 是 Rectangle 的子类，但行为不一致，导致程序逻辑出错 —— 这就违反了里氏替换原则。

遵循LSP的改进设计

要符合LSP，应避免让 Square 错误地扩展 Rectangle 的行为。可以采用组合或重构继承关系。

一种合理方式是：将 Shape 设为抽象类或接口，各图形独立实现：

abstract class Shape {
    public abstract int getArea();
}
<p>class Rectangle extends Shape {
private int width, height;</p><pre class="brush:java;toolbar:false;">public void setWidth(int width) { this.width = width; }
public void setHeight(int height) { this.height = height; }

public int getArea() { return width * height; }

}

class Square extends Shape { private int side;

public void setSide(int side) { this.side = side; }

public int getArea() { return side * side; }

}

此时，Rectangle 和 Square 都继承自 Shape，但在各自逻辑内保持一致性。任何接受 Shape 的方法都可以安全地调用 getArea()，无需关心具体类型。

实际应用中的关键点

• 子类不应改变父类的契约，包括方法的行为语义
• 重写方法时，不能强化前置条件，也不能弱化后置条件
• 尽量用“is-a”的行为含义判断继承关系，而非表面相似
• 当发现子类需要修改父类行为才能正确工作时，应怀疑继承结构是否合理

基本上就这些。里氏替换原则提醒我们：继承不只是代码复用，更是行为契约的延续。设计时多考虑“能否安全替换”，能有效避免后期bug和扩展难题。

到这里，我们也就讲完了《OOP里氏替换原则实例详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！