控制继承深度在两层以内最有效，超三层易致职责不清、修改风险放大、理解成本陡增；应优先用组合、接口、字段标识替代深层继承，父类仅保留稳定语义契约，共性逻辑单层抽象并限子类2–5个。
控制继承深度在两层以内最有效，超过三层就容易职责不清、修改风险放大、理解成本陡增。关键不是“能不能继承”，而是“该不该用继承表达这种关系”。
把继承深度硬性限制在2层内
例如 Animal → Dog 是合理的一层；Dog → ServiceDog 是第二层，已达上限。再往下如 ServiceDog → CertifiedServiceDog 就不该是继承——它本质是角色、配置或策略差异，更适合用字段标识、组合策略或接口实现。
- 团队可在代码规范中明确：“所有具体实现类必须声明为 final”，禁止被继承
- 用 SonarQube 或 IDEA 的 “Inheritance depth” 检查，在 CI 或编码时标黄提示超深类
- 对已有深层链（如 Vehicle → Car → Sedan → ElectricSedan → TeslaModel3），优先识别中间层是否只是分类标签，而非承载复用逻辑
用组合 + 接口替代中间层抽象
当某层类（如 CachedService、ValidatedService）只是给多个子类“打补丁”，说明它实际是能力装配者，不是语义上的“是一种”。这类层正是复杂度温床。
- 把日志、缓存、重试等横切能力定义为接口（Loggable、Cacheable、RetryPolicy），用 default 方法提供基础实现，不带状态
- 原继承结构中删掉 extends，改为持有一个接口字段（如 private final Cacheable cache;），构造器注入
- 让具体类实现顶层业务接口（如 Dao），而不是继承某个抽象基类，保持类型兼容又解耦
基类只保留不可变契约，注入可变参数
父类不应承担太多可变行为。它只定义稳定不变的语义契约（如 “能启动”、“能停止”），而把策略、配置、扩展点显式暴露出来。
立即学习“Java免费学习笔记（深入）”；
- 避免在父类构造器中调用可被重写的方法（易触发 NullPointerException）
- 字段全设为 private，需扩展时提供受控的 protected 方法，而非裸露 protected 字段
- 共性逻辑下沉为单一层级抽象类（如 AbstractRemoteService），但只聚焦一个维度，子类建议控制在 2–5 个
定期识别重构信号
不用等出问题才行动，日常开发中留意这些信号，及时扁平化：
- 某抽象类只有唯一子类 → 很可能过度设计，考虑移除或转为具体类
- 子类大量重写父类方法只为“绕过逻辑” → 那部分逻辑本该抽成可插拔组件
- 继承链中出现空实现（override 空方法）或雷同子类（仅字段不同）→ 说明建模维度错位，应改用配置+组合
- IDE 中“查找所有子类”结果里，多个子类共享的只是几个工具方法 → 抽成工具类或默认方法接口更合适
