应避免抽象类滥用导致继承树过深，优先用接口表达跨类族能力，抽象类仅用于强相关子类的公共实现与契约；超两层继承需警惕虚假血缘，多用组合与策略模式替代深层继承。

避免抽象类滥用导致继承树过深，关键在于回归设计本意：抽象类不是为了“多一层抽象”而存在，而是为强相关子类提供可复用的公共实现 + 强制契约。一旦发现层级超过两层（比如 A → B → C → D），就该警惕是否误把“能力”当“血缘”来建模。

优先用接口表达跨类族的能力

当多个类需要共享某种行为，但彼此并无继承关系时，强行拉出一个抽象父类只会制造虚假继承链。比如“日志记录”“权限校验”“序列化”这些能力，天然属于不同业务域的对象（订单、用户、配置项），它们之间不是“is-a”，而是“can-do”。

• 把 Loggable、Serializable、Validatable 定义为接口，让各业务类按需 implements
• 避免写出 BaseEntity → LoggableEntity → ValidatableEntity → OrderEntity 这种四层抽象链
• 接口不参与继承体系，不会污染类的主继承路径

抽象类只用于真正共用状态与逻辑的子类族

抽象类的价值在于“代码复用 + 模板控制”。只有当一组子类共享字段、构造逻辑、默认实现、且天然属于同一语义范畴时，才值得引入抽象类。

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

• 例如图形系统中：Shape（含 area 字段、getArea() 公共方法）→ Circle/Rectangle，这是合理的一层抽象
• 但如果再抽出 TwoDimensionalShape 和 ThreeDimensionalShape 作为中间层，而实际子类又极少复用其逻辑，就属于过度分层
• 检查抽象类里是否有超过 1–2 个非抽象方法被多数子类直接使用；如果没有，它很可能只是个空壳

用组合替代深层继承，必要时重构为策略+接口

当业务变复杂、子类开始“挑着用”父类功能时，说明继承已失焦。此时应把通用能力拆成独立组件，通过组合注入。

• 比如原设计：PaymentProcessor → AlipayProcessor → AlipayV2Processor（三层），其中仅加密逻辑升级，其余不变
• 重构后：PaymentProcessor 是具体类，依赖 SignatureStrategy 接口，由 AlipayV1Signer / AlipayV2Signer 实现
• 这样新增支付渠道或签名方式，都不再需要动继承结构，也不会加深树高

定期审查抽象类的“存活率”和“使用率”

在代码演进中，有些抽象类会逐渐变成“历史遗迹”——子类越来越少，方法越来越静态，甚至只剩一个实现类。这类抽象类应及时降级或移除。

• 统计每个抽象类下有多少非抽象子类（IDE 或 SonarQube 可辅助）；若长期只有 1 个，考虑合并或转为普通类
• 检查抽象类中的抽象方法是否全部被子类重写；若有方法长期未被实现，说明契约已失效
• 新功能开发时，先问一句：“这个新类，是必须继承它，还是只需具备它的某几个能力？”

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南