里氏替换原则：验证继承关系的正确性方法

里氏替换原则（LSP）的核心在于“换而不变”——子类对象必须能在不修改任何调用代码的前提下，无缝替换父类实例，且行为（返回值、异常、副作用、执行逻辑）完全一致；文章直击实践痛点，教你用三句关键问题快速自检继承合理性，严防方法重写的四大雷区（前置条件收紧、后置条件削弱、异常类型新增、副作用偷换），并强调通过真实测试和工具验证代替主观判断，更进一步指出：当LSP被破坏时，果断放弃强行修补，转而采用接口、组合或抽象基类等更健壮的设计替代方案，让代码真正回归可维护、可扩展的本质。

直接看行为是否“换而不变”：把父类实例替换成子类实例，不改任何调用代码，结果（返回值、异常、副作用、执行逻辑）必须完全一致。这是验证继承关系是否符合里氏替换原则（LSP）最本质、最可靠的方式。

用三句关键问题现场拷问

每次写完子类或重构继承结构时，快速自问：

• 有没有地方把 父类变量声明 换成子类对象后，程序输出变了、抛了新异常、或界面/流程出错？
• 子类是否重写了父类的非 abstract 方法？如果重写了，它是否一字不差地遵守原方法的契约——包括参数范围、返回含义、文档承诺、副作用（比如是否修改状态）、甚至注释里写的特殊规则？
• 子类新增的方法，会不会诱使别人写出 if (obj instanceof SubClass) { ((SubClass)obj).specialMethod(); } 这样的代码？一旦出现，说明这个继承关系本就不该存在。

重点盯住方法重写的四大雷区

子类重写父类已实现方法，是 LSP 最常见的断裂点。务必检查以下四点是否被破坏：

• 前置条件不能收紧：父类方法接受 int amount（允许任意整数），子类就不能只接受正偶数；但可以放宽（比如接受 Number）。
• 后置条件不能削弱：父类承诺“返回非负 BigDecimal”，子类就不能返回可能为负的值；但可以加强（比如保证返回 ≥ 100）。
• 异常类型不能新增：父类方法签名没声明异常，子类就不能在运行时抛出 InsufficientCreditException；若必须处理新情况，应统一在父类中声明基类异常。
• 副作用不能偷换：父类 withdraw() 只扣款，子类就不能悄悄冻结账户或发短信——这些属于新增行为，应通过新方法暴露，而非覆盖原有语义。

用工具+测试做实证验证

别靠感觉，用工程手段落地：

• 在 IDE 中对父类做 Find Usages，找出所有直接使用父类类型声明和调用的地方。
• 逐个把 Parent p = new Parent(); 替换成 Parent p = new Child();，运行原有单元测试——只要一个测试失败，就说明 LSP 被破坏。
• 对关键方法（如 toString()、equals()、save()）单独补契约测试：输入相同参数，断言返回值类型、内容、是否抛异常，与父类行为严格对齐。

当发现不合适时，优先考虑替代方案

一旦确认继承关系踩了 LSP 红线，不要硬修重写逻辑。更健壮的设计通常是：

• 退到接口：让 Rectangle 和 Square 都实现 Shape 接口，各自独立实现 getArea() 和 resize()，不共享可变状态。
• 改用组合：Square 内部持有一个 Rectangle 实例，需要面积时委托调用，需要“宽高同步”逻辑则封装在自身方法里，不污染父类契约。
• 提取抽象基类：若多个子类共用部分行为，可新建一个 abstract 类（如 ResizableShape），把可安全继承的行为放进去，而把易变逻辑留在具体子类中实现。

以上就是《里氏替换原则：验证继承关系的正确性方法》的详细内容，更多关于的资料请关注golang学习网公众号！