接口定义对外契约、确保解耦与替换自由，抽象类封装内部流程、实现复用与控制；二者在模板方法、策略、工厂、适配器等模式中分工明确、不可互换。
接口与抽象类在经典设计模式中不是语法练习题，而是角色分明的协作搭档。理解它们最有效的方式，就是看它们在真实模式里各自承担什么职责、怎么配合、为什么不能互换。
模板方法模式：抽象类当骨架，接口定契约
这是抽象类最典型的用武之地。抽象类负责定义算法流程（比如支付的校验→调用→回调→更新），把不变的部分固化，把变化的部分声明为抽象方法，强制子类实现。
而接口往往在更上层出现——比如整个支付模块对外只暴露 PaymentService 接口，定义 pay()、refund()、query() 这些能力。这样外部系统不关心你是用抽象类封装的支付宝，还是纯手写的数字货币实现，只要它实现了这个接口，就能接入。
- 抽象类解决“怎么一步步做”，聚焦复用和流程控制
- 接口解决“能提供什么服务”，聚焦解耦和替换自由
- 两者一内一外：抽象类在实现层组织逻辑，接口在交互层划清边界
策略模式：接口是核心，抽象类可选辅助
策略模式强调运行时切换算法，它的主干完全依赖接口。比如 DiscountStrategy 接口只声明 calculate(double amount)，不同策略（满减、会员折、限时券）各自实现。
立即学习“Java免费学习笔记（深入）”；
如果多个策略共享一些计算逻辑（比如都需校验用户等级、都需格式化金额），这时可以加一个 AbstractDiscountStrategy 抽象类，把公共校验、日志、缓存等写在里面，再让具体策略继承它。但注意：客户端代码仍只面向 DiscountStrategy 接口编程，抽象类只是内部优化，对外不可见。
- 接口保证策略可插拔、可测试、可Mock
- 抽象类只是“锦上添花”，用于消除策略间的重复代码
- 没有抽象类，策略模式照样成立；没有接口，策略模式就失去意义
工厂+抽象类+接口组合：三层分工清晰
以数据解析为例：业务方需要解析 CSV、JSON、XML。你可以这样分层：
- 顶层定义 DataParser 接口：规定所有解析器必须支持
parse(String input)和getFormatName() - 中间提供 AbstractDataParser 抽象类：统一处理空输入校验、日志记录、异常包装，只留
doParse()让子类实现 - 底层是 CSVParser、JsonParser 等具体类，继承抽象类并实现接口
工厂类（如 ParserFactory）根据文件后缀返回对应解析器实例，但返回类型是 DataParser 接口。使用者完全不知道背后有没有抽象类，也不需要知道。
这种结构让扩展变得简单：新增 YAML 解析，只需写一个新类继承抽象类、实现接口，工厂加一行判断即可，其他代码零改动。
适配器模式中的角色反转：接口暴露，抽象类隐藏细节
当你需要把旧系统（比如一个只有 sendMsg() 方法的老短信类）接入新规范（比如统一的 NotificationService 接口，要求有 notify(User user, String content)），适配器就出场了。
你可以写一个 SmsAdapter 类，实现 NotificationService 接口，并在内部持有一个老短信对象。这时接口是“门面”，抽象类反而不必要——因为适配逻辑通常单一，无需复用。
但如果多个旧系统（邮件、钉钉、企业微信）都要适配同一套新接口，且它们都有共同初始化、重试、限流逻辑，就可以提取一个 AbstractNotifierAdapter 抽象类，把通用部分抽出来，再让每个具体适配器继承它。
- 接口确保“对外一致”
- 抽象类确保“对内不重复”
- 谁暴露给调用方，谁就该是接口；谁只服务实现者，才考虑抽象类
