抽象类单继承非缺陷而是设计约束，应以接口组合替代多继承：抽象类定义“是什么”，接口定义“能做什么”，通过正交小接口（如Persistable、CacheEvictable）实现横向扩展与语义解耦。
Java 中抽象类的单继承限制无法绕过，但完全不必绕过——它本就不是缺陷，而是设计约束。真正要突破的，是“只靠继承组织行为”的思维惯性。应对复杂多变需求，关键在于用对机制：抽象类管“是什么”，接口管“能做什么”，两者配合才是正解。
用多个接口组合能力，而不是堆砌抽象类
一个类不能 extends 多个抽象类，但可以 implements 多个接口。比如业务对象既要可持久化、又要可比较、还要支持缓存失效：
-
定义正交接口：如
Persistable、Comparable<Order>、CacheEvictable，每个只聚焦一件事； -
实现类直接组合：class
Order implements Persistable, Comparable<Order>, CacheEvictable； -
避免语义污染：不把“日志记录”或“权限校验”塞进核心抽象类，而是抽成
Loggable、Authorizable接口按需实现。
抽象类 + 接口协同：分层复用 + 横向扩展
抽象类负责领域内共性骨架，接口负责跨域能力插拔。例如电商系统中：
- 定义抽象基类
AbstractProduct，封装 SKU、库存、上下架状态等通用逻辑； - 让具体商品类继承它，再按需实现
Searchable（支持全文检索）、Recommendable（参与推荐算法）、Exportable（导出为 Excel）； - 这样既保持了继承链清晰，又让能力可增可删，不破坏原有结构。
处理默认方法冲突：主动决策，不回避
当两个接口都提供了同名 default 方法（如 toJson()），编译器会报错，这反而是好事——它强制你明确语义：
立即学习“Java免费学习笔记（深入）”；
- 在实现类中显式重写该方法，哪怕只是调用其中一个：
InterfaceA.super.toJson()； - 若逻辑需融合，就在重写方法里组合调用，比如先序列化基础字段，再追加扩展字段；
- 不要依赖实现顺序，也不要试图“屏蔽”某个接口的方法——接口契约一旦暴露，就该被尊重和明确响应。
比语法更重要：接口粒度与命名即设计
能否应对复杂变化，不取决于能不能写 implements A, B, C, D，而在于这些接口是否真正正交、稳定、可测试：
- 避免大而全的接口（如
BusinessService），它会让实现类被迫承担无关职责； - 倾向小而专的接口（如
CanRetry、HasDeadline、SupportsVersioning），便于组合、mock 和演进； - 接口名用动词短语，强调能力而非角色，更易理解意图，也更利于未来新增实现类时快速判断是否适用。
