控制继承深度在2层以内最直接有效，将“是一种”严格限定于本质类型变化，其余扩展改用组合、接口和策略注入；所有具体类标记final；中间层抽象替换为接口+委托；基类只保留不可变契约；定期清理退化层。
控制继承深度在2层以内最直接有效，把“是一种”的语义严格限定在本质类型变化上，其余扩展改用组合、接口和策略注入。
把继承链硬卡在两层
Animal → Dog 是合理的一层；Dog → ServiceDog 是第二层，到此为止。再往下延伸（比如 ServiceDog → CertifiedServiceDog）大概率不是新类型，而是配置、角色或策略差异。此时应触发重构信号，而不是继续加子类。
- 所有具体实现类标记为 final，禁止被继承
- 在 CI 阶段用 SonarQube 或 IDEA 的 “Inheritance depth” 检查拦截超深结构
- IDEA 中开启检查后，超过2层的类会标黄提示，便于早期发现
中间层抽象一律替换成接口+委托
像 LoggingService、CachedService、ValidatedService 这类名字带“Service”的中间类，往往只是给多个子类“打补丁”，实际是能力装配职责，不是语义上的“是一种”。它们正是复杂度温床。
- 把 LoggingService 改成 Loggable 接口 + DefaultLogger 实现，由业务类通过字段持有
- 将 ValidatedService 抽成 ValidationRule 策略对象，构造时传入，而非继承固定逻辑
- 每个业务类只依赖所需能力，调用链清晰，单元测试只需 mock 单个组件
基类只保留不可变契约
父类一旦悄悄塞进可变细节（如默认数据库连接、硬编码重试次数、特定异常包装），子类就只能绕着走或强行覆盖，破坏封装。
立即学习“Java免费学习笔记（深入）”；
- 基类中避免 protected 字段，尤其 List、Map 等可变容器——子类随意修改会导致状态不一致
- 拒绝业务逻辑渗透：校验规则、配置加载、线程模型等都应外置，不写死在父类里
- 若必须暴露方法给子类，用 protected 前务必加文档说明输入/输出/副作用
定期识别并清理退化层
有些抽象层已失去存在意义：子类多数只是透传 super.xxx()，或仅覆盖一两个空方法，这类“伪抽象”该合并就合并，该删就删。
- 在 IDE 中右键关键方法 → “Find Usages” → 切换到 “Hierarchy” 视图，若显示超5个子类且多为透传，说明该层已退化
- 用 javap -v ClassName 查看 Constant Pool，确认方法引用是否还指向深链中的抽象声明
- 启用 JVM 参数 -XX:+PrintInlining，观察关键方法是否长期显示 not inlineable——这是继承过深、JIT 放弃优化的信号
