接口定义“能做什么”，抽象类封装“怎么做的一致骨架”；接口用于能力契约与变化隔离，抽象类用于通用流程复用；二者应组合使用，避免职责混淆与设计陷阱。
设计松耦合系统时，接口和抽象类不是替代关系，而是分工协作：接口定义“能做什么”，抽象类封装“怎么做的一致骨架”。关键在让模块只依赖约定，不依赖实现细节。
用接口定义能力契约，隔离变化点
当多个模块需要协作但又不想彼此牵扯时，优先用接口。它只声明行为边界，不暴露实现逻辑。
- 比如日志模块与业务模块之间，定义ILoggable接口，只含
logError(String)、getLogId()等方法 - 业务类持有ILoggable引用，运行时通过依赖注入传入
FileLogger或CloudLogger - 后续切换日志框架，只需新增实现类，业务代码完全不动
- 避免把接口设计成“大而全”，一个接口方法超过5个就该考虑拆分（如Readable、Writable、Searchable）
用抽象类封装通用流程，复用核心逻辑
当一组子类共享大量相同步骤，仅少数环节差异化时，抽象类更合适。它提供可继承的模板和构造能力。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如报表生成系统，定义ReportGenerator抽象类，含
generateReport()模板方法 - 该方法内部调用
readData()（abstract）、formatData()（abstract）、exportReport()（已实现） -
exportReport()统一处理压缩、加水印、生成文件名等共性逻辑，子类无需重复编写 - 子类如
ExcelReportGenerator只需专注实现读取和格式化，自然复用父类骨架 - 抽象类可带构造器、实例变量、protected字段——这些是接口无法提供的能力
组合使用：接口定契约，抽象类给默认实现
JDK 8+支持接口default方法，但不能因此混淆职责。接口仍以声明为主，default仅用于极简无状态逻辑。
- 支付场景中，Payment接口声明
process()和refund()，体现能力契约 - AbstractCreditCardProcessor抽象类封装卡号加密、风控校验、交易流水生成等有状态流程
- 接口中的default方法适合写
Objects.requireNonNull()校验或toString()简单转换，不适合含数据库连接、缓存操作或需构造参数的逻辑 - 若某功能既需状态管理又需多继承支持，应让具体类同时
extends抽象类 +implements多个接口
避开常见设计陷阱
错误选择会悄悄增加维护成本，尤其在系统演进过程中。
- 把本该是能力契约的场景写成抽象类（如Flyable做成抽象类），导致子类被迫继承无关字段或
final方法 - 在抽象类中塞满
static工具方法或过度使用final修饰，限制子类扩展自由度 - 让接口承担初始化职责（如要求实现类必须调用某个init()方法），这违背接口“只声明不管理生命周期”的原则
- 抽象类中混入业务判断逻辑（如
if (user.isVIP())），应移至策略模式或配置驱动的实现类中
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
