JavaLSP原则：子类如何正确扩展父类功能

里氏替换原则（LSP）的本质不是语法兼容，而是语义守约：子类必须在父类定义的行为契约内安全扩展功能，而非以“能编译通过”为底线；现实中大量运行时错误——如价格反向上涨、静默数据丢失、突发UnsupportedOperationException——正源于对异常范围、前置条件或后置条件的无意识破坏；真正可靠的保障不靠IDE警告或继承深度，而在于用契约测试覆盖所有子类、借助模板方法或组合实现正交增强，并在每次新增子类时回归验证已有逻辑——因为LSP的终极考验，是第七个子类上线时，前六个客户的订单依然准确扣款。

为什么子类重写方法后，父类引用调用出错了

里氏替换原则不是“只要能编译通过就行”，而是要求子类对象在任何父类出现的地方，行为不破坏原有逻辑。常见错误是：子类重写了 calculateDiscount()，但把原本返回正数的逻辑改成可能返回负数，而下游代码直接用结果做减法，导致价格变正数反而涨价。

• 典型现象：ClassCastException 不会出现，但运行时数值错乱、空指针、状态不一致——这类问题往往测试覆盖不到父类上下文
• 关键判断点：看父类方法的契约（文档、注释、已有单元测试），不是看签名是否匹配
• 如果父类 save() 方法保证“成功即持久化”，子类就不能改成只写缓存、延迟落库，除非父类契约本身就允许

用 @Override 修饰但依然违反 LSP 的三种情况

Java 编译器只检查签名，不校验语义。以下操作语法合法，却实质破坏 LSP：

• 扩大异常范围：父类 parseJson() 声明抛 IllegalArgumentException，子类重写后抛 IOException —— 调用方没准备捕获后者
• 削弱前置条件：父类要求 id != null，子类实现里允许 id == null 并返回默认值，看似友好，但可能掩盖上游传参错误
• 加强后置条件：父类 getItems() 返回可修改的 List，子类返回 Collections.unmodifiableList() —— 调用方原逻辑是先 add() 再处理，现在直接 UnsupportedOperationException

如何让子类安全地“增强”父类功能

增强 ≠ 改变契约。真正符合 LSP 的增强，是在父类定义的边界内做扩展：

• 用模板方法模式：父类定义 process() 框架，留空钩子 beforeValidate() 和 afterSave()，子类只覆写钩子，不碰主流程契约
• 组合优于继承：把“增强逻辑”抽成策略对象，例如父类 PaymentProcessor 持有 FeeCalculator 接口，子类换实现，而非重写 calculateTotal()
• 若必须重写，用守卫断言显式声明约束：在子类 withdraw() 开头加 assert balance >= amount : "balance check violated";，比静默失败更容易暴露问题

IDE 和测试怎么帮我们守住 LSP

没有自动检查工具，但可以低成本拦截大部分问题：

• 给父类每个 public 方法写契约式测试（比如“输入负数应抛 IllegalArgumentException”），所有子类共用同一套测试用例 —— 这比文档可靠得多
• IntelliJ 中开启 “Inheritance hierarchy” 视图，右键父类方法 → “Find Usages” → 切到 “Implementations” 标签页，一眼看出哪些子类重写了它，立刻人工核对行为一致性
• 避免在子类中出现 if (this instanceof SubClass) 分支：这是典型的“向下类型检查”，说明父类抽象已失效，LSP 实际已被放弃

真正难的不是写对一个子类，而是在新增第 7 个子类时，还能确保前 6 个的调用逻辑不受影响——这时候契约测试和小步重构比设计模式更重要。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~