抽象类与接口混合使用的核心思路是用接口定义能力契约、抽象类填充实现骨架：接口先行明确最小契约并保持解耦，抽象类居中封装共性逻辑并支持扩展，具体类收尾专注差异化实现，且抽象类可实现多个接口以聚合能力。
抽象类与接口混合使用的核心思路是：用接口定义“能力契约”，用抽象类填充“实现骨架”。二者不是替代关系，而是分工协作——接口负责对外稳定、解耦、组合；抽象类负责对内复用、封装、扩展。
接口先行：定义统一能力边界
先设计接口，明确模块间交互的最小契约。它不关心谁实现、怎么实现，只约定“能做什么”。
- 例如定义 PaymentProcessor 接口，仅含
process()和refund()两个方法，所有支付渠道（微信、支付宝、银行卡）都实现它 - 接口方法粒度要小、职责单一，避免一个接口塞10+方法；可拆为 Payable、Refundable、Queryable 等多个小接口
- 对外发布的 SDK 或跨团队协作模块，优先暴露接口类型，而非具体类或抽象类引用
抽象类居中：封装可复用的通用逻辑
在接口基础上，提供一个默认实现载体，把共性流程、状态管理、初始化校验等逻辑集中到抽象类中。
- 例如 AbstractCreditCardProcessor 实现 PaymentProcessor 接口，并内置卡号脱敏、风控调用、重试计数（
retryCount字段）、统一异常包装等逻辑 - 抽象类可声明
protected abstract方法（如doCharge()），留给子类定制核心差异点 - 它支持构造器参数（如传入
Config config），接口做不到这点；也能持有实例变量，default 方法无法访问 this
具体类收尾：专注差异化实现
最终的具体实现类，只做最轻量的事：继承抽象类 + 实现少数抽象方法 + 按需覆盖默认行为。
- 比如 WechatPayProcessor 继承 AbstractCreditCardProcessor，只实现
doCharge()调用微信统一下单 API - 若某渠道不需要重试逻辑，可选择不继承该抽象类，而直接实现接口——架构保留了灵活性
- 新增渠道时，90% 逻辑已由抽象类提供，只需关注 1–2 个关键方法，开发成本低、出错率低
进阶协同：抽象类实现多个接口
一个抽象类可以同时实现多个接口，把分散的能力聚合为可复用的“能力包”。
- 例如 FileBasedSavable 抽象类同时实现 Savable 和 Validatable 接口，统一处理存储空间检查、格式校验、失败日志等公共逻辑
- 子类如 LocalFileSavable 或 CloudBackupSavable 自动获得两套能力，无需重复写校验代码
- 这种模式特别适合中间件组件（如日志、缓存、序列化模块），既保持接口的正交性，又提升落地效率
