应避免抽象类滥用导致继承树过深，优先用接口表达跨类族能力，抽象类仅用于强相关子类的公共实现与契约；超两层继承需警惕虚假血缘，多用组合与策略模式替代深层继承。
避免抽象类滥用导致继承树过深，关键在于回归设计本意：抽象类不是为了“多一层抽象”而存在，而是为强相关子类提供可复用的公共实现 + 强制契约。一旦发现层级超过两层（比如 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 个非抽象方法被多数子类直接使用；如果没有，它很可能只是个空壳
用组合替代深层继承，必要时重构为策略+接口
当业务变复杂、子类开始“挑着用”父类功能时，说明继承已失焦。此时应把通用能力拆成独立组件，通过组合注入。
立即学习“Java免费学习笔记（深入）”；
- 比如原设计：
PaymentProcessor → AlipayProcessor → AlipayV2Processor（三层），其中仅加密逻辑升级，其余不变 - 重构后：
PaymentProcessor是具体类，依赖SignatureStrategy接口，由AlipayV1Signer/AlipayV2Signer实现 - 这样新增支付渠道或签名方式，都不再需要动继承结构，也不会加深树高
定期审查抽象类的“存活率”和“使用率”
在代码演进中，有些抽象类会逐渐变成“历史遗迹”——子类越来越少，方法越来越静态，甚至只剩一个实现类。这类抽象类应及时降级或移除。
- 统计每个抽象类下有多少非抽象子类（IDE 或 SonarQube 可辅助）；若长期只有 1 个，考虑合并或转为普通类
- 检查抽象类中的抽象方法是否全部被子类重写；若有方法长期未被实现，说明契约已失效
- 新功能开发时，先问一句：“这个新类，是必须继承它，还是只需具备它的某几个能力？”
