控制继承树深度至2层内最有效，超深继承导致职责模糊、风险放大；应禁用子类继承、用组合+接口替代中间层；基类只保留不可变契约，注入可变参数；定期通过类图识别扇出过高、空实现泛滥、子类雷同等重构信号。
控制继承树深度是降低面向对象设计复杂度最直接有效的手段。深层继承（如超过3层）会让类之间的职责边界模糊、修改风险放大、测试和理解成本陡增，本质上不是“建模得细”，而是“耦合得紧”。关键不在于能否继承，而在于是否必须继承、是否值得用继承来表达。
把继承深度硬性限制在2层以内
这是多数成熟团队落地最有效的约束。例如 Animal → Dog 是合理的一层继承；若再加一层 Dog → ServiceDog，则已到两层上限。再往下延伸（如 ServiceDog → CertifiedServiceDog）就应触发警觉——此时新增的差异大概率属于配置、策略或角色，而非本质类型变化。
- 团队可在代码规范中明确：“子类不得再被继承”，即所有具体实现类标记为 final
- 用静态分析工具（如 SonarQube 的 java:S1118 或自定义规则）在 CI 阶段拦截超深继承，避免人工审查遗漏
- IDEA 中可启用 “Inheritance depth” 检查，对超过2层的类标黄提示
用组合+接口替代中间层抽象
当发现某层类（如 LoggingService、CachedService、ValidatedService）只是给多个子类“打补丁”，它实际承担的是能力装配职责，而非语义上的“是一种”。这类中间层正是复杂度温床。
- 把 LoggingService 改为 Loggable 接口 + DefaultLogger 实现类，由业务类通过字段持有
- 将 ValidatedService 抽成 ValidationRule 策略对象，构造时传入，而非继承固定校验逻辑
- 这样每个业务类只依赖所需能力，调用链清晰，单元测试只需 mock 单个组件，无需构造整棵继承树
基类只保留不可变契约，拒绝业务逻辑渗透
脆弱基类的根源，常是父类悄悄塞进了本该由子类决定的行为：默认数据库连接、硬编码重试次数、特定异常包装方式等。这些细节一旦写死，子类就只能“绕着走”或“强行覆盖”，破坏封装。
- 基类方法尽量声明为 final，仅留少数 hook（如 protected abstract doProcess()）供子类定制核心逻辑
- 所有可变参数（超时、序列化格式、日志级别）必须通过构造函数或 builder 注入，不设默认值字段
- 基类单元测试只验证流程契约（如“before → doProcess → after 必然按序执行”），不测具体行为实现
定期用类图识别继承结构退化信号
大型项目中，继承关系会随迭代悄然异化。每季度用 IDEA 的 Diagram 功能或 JDepend 生成继承图谱，重点关注三类红灯信号：
- 扇出过高：一个基类被10个以上子类继承，说明它可能混杂了多个关注点，该拆
- 空实现泛滥：多个子类只重写一两个方法，其余全空实现，说明抽象粒度太粗，接口比继承更合适
- 子类高度雷同：若干子类代码相似度＞80%，却未提取共性，暴露基类抽象不足或重复代码
发现任一信号，就启动小步重构：先提取角色接口，再逐步将子类迁出继承链，用组合收编变体逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
