接口管“能做什么”，抽象类管“怎么去做一半”；接口定义行为契约，抽象类提供部分实现并留定制空间；多实现选接口，共用逻辑多选抽象类。

接口与抽象类不是用来背概念的，而是解决具体问题的工具。用对了，代码结构清晰、扩展容易；用错了，反而增加理解成本和维护负担。

明确分工：接口管“能做什么”，抽象类管“怎么去做一半”

接口定义行为契约，不关心实现细节；抽象类提供部分通用实现，同时保留子类定制空间。

• 当多个类需要统一调用方式但实现完全不同（比如支付方式：微信支付、支付宝、银联），优先用接口——interface Payment声明pay()和refund()，各实现类自由发挥
• 当多个类有大量共用逻辑，但关键步骤必须由子类决定（比如不同报表导出：Excel、PDF、CSV），适合抽象类——abstract class ReportExporter封装文件命名、数据预处理、日志记录，只把doExport()留为抽象方法
• 一个类可以实现多个接口，但只能继承一个抽象类。如果业务需要组合能力（如“可导出”+“可打印”+“可缓存”），接口更灵活

实战中常被忽略的关键细节

很多问题不是不会用，而是没注意约束条件和协作方式。

• 接口中的方法默认是 public abstract，不能加访问修饰符；字段默认是 public static final，别试图在接口里写可变状态
• 抽象类的构造函数可以有参数，用于初始化共享资源（如数据库连接池、配置对象），子类通过super(...)传递
• Java 8+ 接口可含 default 方法，适合给已有接口“安全升级”——比如新增retry()逻辑，老实现类不用改就能用；但别滥用，default 方法应是真正通用的辅助逻辑，不是主干流程
• 抽象类中可以有普通方法、静态方法、甚至 main 方法，方便单元测试或独立运行验证基础流程

组合使用：用接口定义能力，用抽象类组织实现

真实项目里，二者经常配合出现，形成稳定又灵活的骨架。

• 先定义接口：interface DataProcessor，声明process(List)和validate(Record)
• 再写抽象基类：abstract class BaseDataProcessor implements DataProcessor，内置通用校验规则、异常包装、耗时统计等，只让子类专注doProcess()
• 最后具体实现：class OrderProcessor extends BaseDataProcessor，只需补全订单特有的转换逻辑，其余都复用
• 这样既保证所有处理器对外行为一致（接口约束），又避免重复造轮子（抽象类封装）

低代码场景下的智能选择策略

在代码生成器或平台化开发中，接口与抽象类的选择可自动化。

• 若业务模块强调协议兼容性（如对接第三方系统、开放API），生成接口骨架，确保契约稳定
• 若模块强调流程一致性（如审批流、风控引擎），生成抽象类骨架，强制继承统一前置/后置处理
• 规则引擎可基于注解判断：标注@ApiContract → 生成接口；标注@WorkflowCore → 生成抽象类
• 生成后保留扩展点，比如抽象类里留protected void beforeProcess() {}空钩子，子类按需重写