接口定义“能做什么”，抽象类封装“怎么一步步做”；接口划清能力边界、隔离变化，抽象类固化流程骨架、复用稳定逻辑，二者应按职责组合使用而非语法取舍。

规划系统顶层设计时，接口与抽象类不是语法选择题，而是职责划分问题：接口定义“能做什么”，抽象类封装“怎么一步步做”。关键不在用哪个，而在每个模块该承担什么角色。

用接口划清能力边界，隔离变化源头

当多个模块需要协作但彼此不该知道对方细节时，接口是第一道防线。比如消息通知系统，业务层不关心发的是短信、邮件还是微信，只依赖一个 NotificationService 接口：

• 接口只声明 send(Recipient, Content) 和 isAvailable() 这类无状态契约
• 所有实现类（SmsNotifier、WechatNotifier）互不影响，新增渠道不改已有代码
• 上层可统一注入、切换、Mock，甚至运行时按策略路由

用抽象类固化流程骨架，复用稳定逻辑

当一组子类共享固定执行步骤，仅局部行为不同，就该用抽象类。典型如数据导出服务：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• AbstractExporter 定义模板方法 export()：先校验 → 再查询 → 然后格式化 → 最后落盘
• 其中 validate() 和 saveToFile() 是已实现的通用逻辑
• fetchData() 和 format() 声明为 abstract，由 ExcelExporter 和 PdfExporter 各自实现

组合使用：接口暴露能力，抽象类交付默认实现

JDK 8+ 的 default 方法不是让接口变抽象类，而是补小缺口。设计时要守住分寸：

立即学习“Java免费学习笔记（深入）”；

• 接口里的 default 方法只做无副作用的简单操作，比如 toString() 的空值兜底、isNotBlank() 这类工具逻辑
• 涉及资源管理（如数据库连接）、状态维护（如重试计数）、构造参数依赖的逻辑，必须放进抽象类——接口没有构造器，也无法持有实例字段
• 例如 PaymentProcessor 是接口，AbstractAlipayProcessor 封装签名生成、异步回调验证等共用流程

避开常见设计反模式

顶层设计一旦错位，后期重构成本极高：

• 把本该是能力契约的场景写成抽象类（如 Flyable 设计为抽象类），会让子类被迫继承无关字段或生命周期方法
• 在一个接口里堆砌十多个方法，导致实现类大量空方法重写——应拆成 Readable、Searchable、Exportable 等细粒度接口
• 抽象类里塞满 final 方法或静态工具方法，等于提前锁死扩展点，违背开闭原则