继承不该滥用，因其导致强耦合、测试困难、修改风险高；应审慎判断是否使用，优先考虑接口与组合，控制继承深度在1–2层，并用final防止不当扩展。
Java中继承不是不能用，而是不该滥用。它看似简化了代码复用，实则悄悄抬高了系统理解成本、测试难度和修改风险。真正稳健的设计，往往始于对“要不要继承”这个问题的审慎判断。
继承天然带来强耦合
子类和父类绑得太紧：父类一改，所有子类都可能出问题；父类加个字段或方法，子类哪怕用不上，也得被动承载。这不是复用，是“强制搭载”。尤其当父类并非专为继承而设计时（比如工具类、历史遗留类），子类很容易被拖进实现细节的泥潭，丧失独立演进能力。
- 父类私有成员不可见，但受保护成员又让子类过度依赖内部结构
- 子类重写方法时，若未正确调用super逻辑，容易破坏父类契约
- 单元测试时，子类行为常需连带验证父类状态，测试边界模糊
is-a关系常被误读
“正方形是矩形”在数学上成立，但在面向对象里未必适合继承。因为正方形对边长有严格约束（四边相等），而矩形允许长宽不同——子类反而比父类更受限。继承隐含“子类可替代父类使用”（Liskov替换原则），但把正方形实例传给只接受矩形参数的方法，一旦该方法尝试修改长、宽为不同值，就会出错。
- 继承应基于“可扩展性”，而非单纯语义归属
- 松树是树 → 合理（松树拥有树的所有通用特征，并增加新属性）
- 正方形是矩形 → 危险（正方形削弱了矩形的关键可变性）
单继承限制真实世界建模能力
现实中的对象常具备多重角色：一个“智能音箱”既是“网络设备”，又是“音频播放器”，还是“语音助手”。Java只允许一个extends，无法同时继承三者的行为。开发者被迫做取舍，或硬造一个“大父类”，或把逻辑塞进某个不相关的父类下，最终导致职责不清、维护困难。
- 接口（interface）更适合表达“能做什么”，比如NetworkCapable、Playable
- 组合（composition）更适合表达“由什么组成”，比如Speaker内部持有AudioEngine和WifiModule
- Java 8+默认方法和静态接口方法，已大幅弥补接口过去无法提供行为的短板
继承树过深会稀释设计意图
超过三层的继承链（如Animal → Mammal → Carnivore → Lion）会让最底层类背负大量间接继承的字段与方法，其中很多根本用不到。调试时难以追踪方法实际来自哪一层，重构时牵一发而动全身。
- 推荐控制在1–2层：顶层抽象定义契约（如WaterHeating抽象类），直接子类专注具体实现
- 避免“为了抽象而抽象”，没有共用逻辑的类强行拉进继承体系，只会增加噪音
- 用final修饰不打算被继承的类，是对未来维护者的明确提示
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
