继承链超三层需警惕，易致职责混淆与维护困难；应优先组合替代继承，接口定义契约，抽象类共享逻辑但限单层；final用于明确无扩展意图的类或方法。
继承链超过三层就该警惕
Java里继承不是越多越好，深度超过 class A extends B extends C extends D 这种三层结构，往往意味着职责混淆或抽象失当。编译器不拦你，但后续修改时，super.super.method() 这种调用几乎无法维护，子类对父类的隐式依赖也会越来越脆弱。
实操建议：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 用
javap -c查看字节码，确认实际方法分派路径——如果发现INVOKESPECIAL频繁跨多层，说明继承已成负担 - 把“是”关系（is-a）严格限定在领域模型顶层：比如
AdminUser是User，但AdminUserWithExportPrivilege就不该再继承AdminUser，而应组合ExportCapability - IDE里按住 Ctrl（或 Cmd）点击父类名，如果跳转后看到 5 个以上未被重写的空方法或仅含
throw new UnsupportedOperationException()的桩，这就是抽象过度的信号
用组合替代继承时怎么选接口还是抽象类
关键不在“要不要抽象”，而在“谁负责决定行为契约”。如果能力模块需要强制实现某些方法（比如必须提供 serialize() 和 validate()），用接口；如果还要共享默认逻辑（比如日志埋点、重试封装），优先用抽象类，但只允许单层继承。
常见错误现象：NoClassDefFoundError 在运行时爆发，往往是因为抽象类里引用了子类尚未加载的静态资源，而接口不会触发这种初始化顺序问题。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 定义能力模块时，先写接口，再补一个
DefaultXxxService抽象类（带protected工具方法），让具体类选择继承或仅实现接口 - 避免在抽象类构造器里调用
protected abstract方法——子类字段可能还未初始化，JVM 不报错但值为null或0 - 接口方法加
default要克制：一旦多个 default 方法互相调用，又在不同实现类中被重写，调用栈会绕晕人
final 类和方法在继承控制中的真实作用
final 不是“防篡改保险柜”，而是明确告诉协作者：“这里没有扩展意图”。很多团队滥用 final 拦截继承，结果导致测试时只能用 PowerMock 拦截 new，反而增加耦合。
真正该加 final 的地方很窄：
- 工具类如
StringUtils，所有方法都是静态且无状态，就不该被继承 - 核心实体类如
Money、OrderId，值对象一旦可变，领域一致性就崩了 - 模板方法模式里的钩子方法（hook method）之外的所有
final方法，防止子类绕过流程校验
注意：final 类不能被 Mockito mock（除非用 inline mock），所以单元测试里若发现大量 when(mock.xxx()).thenReturn(...) 针对 final 方法失败，就是设计边界模糊的征兆。
重构继承树时如何验证行为一致性
把 extends 改成 has-a 后，最怕的是语义漂移：比如原来 PaymentProcessor 继承 LoggingAware，现在用组合，但忘了在 process() 入口统一打日志。
实操建议：
- 提取共通行为前，先用 IDE 的 “Extract Superclass” 功能生成候选抽象类，再人工删掉所有仅被单个子类使用的字段和方法
- 用
@Override注解强制覆盖父类方法——如果子类没加这个注解却重写了方法，说明它可能误以为自己在扩展，实际只是在修复父类缺陷 - 写回归测试时，别只测 happy path；重点覆盖父类抛异常、返回 null、并发调用等边界场景，确保组合后的对象响应一致
继承不是坏味道，但它是高阶语法糖，吃多了容易腻。真正难的不是“能不能继承”，而是每次敲下 extends 时，有没有想清楚：这个父类，三年后还有人愿意读它的 Javadoc 吗？
