继承层级过深会降低可读性、增加维护成本并引发脆弱基类问题；应优先用组合替代非“是一种”关系的继承，控制继承深度在三层以内，以接口定义能力，并逐步重构遗留深继承。
继承层级过深会降低代码可读性、增加维护成本，还容易引发脆弱基类（Fragile Base Class）问题。解决核心不是“少用继承”，而是用更合适的关系替代“不必要”的继承。
用组合替代深层继承
当子类只是需要复用父类的部分能力，而非“是一种”关系时，优先考虑组合。例如，一个ReportGenerator类不需要继承DatabaseConnection，而应持有其引用：
- 把DatabaseConnection作为ReportGenerator的私有字段
- 通过方法参数或构造器注入依赖，便于单元测试和替换实现
- 避免子类意外重写父类关键逻辑（如连接池关闭时机被覆盖）
提取中间抽象层，控制深度在3层以内
若必须保留继承链，建议将共性行为向上收敛，限制层级为接口/顶层抽象类 → 中间契约类 → 具体实现类三层。例如：
- Shape（抽象类，定义area()和render()）
- ResizableShape（添加resize()，仅被需要缩放的图形继承）
- Circle、Rectangle直接继承ResizableShape，不再出现Circle ← Shape2D ← Shape ← Drawable这样的四层结构
用接口定义能力，避免“继承即功能叠加”
深层继承常源于把不同职责硬塞进同一继承线（如“能打印+能导出+能加密”全靠层层继承）。改用接口明确角色：
立即学习“Java免费学习笔记（深入）”；
- 定义Printable、Exportable、Encryptable等小接口
- 具体类按需实现，如PdfDocument implements Printable, Exportable
- 避免因新增能力被迫修改整个继承树，也利于运行时动态组合行为（配合策略模式）
重构已有深继承：先封装，再拆分
对遗留系统中已存在的深层继承（如A ← B ← C ← D ← E），不要一次性推倒重来。可逐步优化：
- 先将E中与D无关的逻辑抽成独立工具类或服务类
- 在C或D层引入protected方法或模板方法，把可变部分隔离出来
- 用IDE的“Extract Superclass”辅助识别真正共用的部分，删除冗余中间层
