OOP中的里氏替换如何在代码中体现_Java继承规范说明

里氏替换原则要求子类能安全替换父类而不破坏程序正确性，强调行为契约、前置/后置条件、不变量、构造逻辑及副作用控制，而非仅语法兼容。

里氏替换原则（Liskov Substitution Principle, LSP）不是“能编译通过就行”，而是要求子类对象在任何父类出现的地方，都能不改变原有程序正确性地替换父类对象。它本质是对继承关系的语义约束，不是语法检查，Java 编译器不会报错，但违反时运行结果可能出人意料。

方法签名一致，且行为契约不变

子类重写父类方法时，不能缩小访问权限（如父类 public，子类不能改为 protected），也不能抛出父类方法没声明的新受检异常。更重要的是：方法的前置条件不能增强，后置条件不能减弱。

• 比如父类 withdraw(double amount) 允许取任意正数，子类不能加限制“只允许取整数元”——这会破坏调用方假设
• 父类约定“返回非 null 账户对象”，子类就不能返回 null 或抛出未声明异常

子类不能破坏父类的不变量（invariants）

父类维护的关键状态规则，子类必须严格遵守。例如：

父类 Rectangle 有 width 和 height，面积 = width × height；
子类 Square 继承它并让 setWidth() 同时设 height，看似合理，但会导致 area() 行为不可预测——当外部代码按矩形逻辑调用 setHeight(2); setWidth(3);，期望面积是 6，实际却得 9。

这种设计违反 LSP，应避免用继承表达“正方形是矩形”的数学关系，改用组合或接口更稳妥。

构造逻辑需兼容父类预期

子类构造器必须确保对象创建后即满足父类定义的有效状态。例如：

• 父类 Person 要求 name 非空，子类 Student 构造时若允许传入空字符串并静默处理，就破坏了该不变量
• 父类初始化中依赖某个字段已就绪，子类重写被调用的初始化方法时，不能跳过或延迟关键赋值

多态调用下，子类不应引入意外副作用

如果父类方法设计为“只读”或“幂等”，子类重写时不应偷偷修改状态或产生可观测副作用。例如：

父类 getData() 文档注明“不修改内部缓存”，子类若在其中触发刷新并清空旧数据，下游依赖该行为的代码就可能失效。

这类问题往往在单元测试中暴露——用父类类型声明、子类实例赋值，再跑父类原有测试用例，若失败，大概率是 LSP 被破坏。

基本上就这些。LSP 不是教条，而是提醒你：继承不是为了“少写代码”，而是为了“可安全替换”。设计时多问一句：“别人拿我这个子类去换父类，会不会懵？” —— 答案是否定的，才真正符合里氏替换。