接口定义能力契约，支撑策略、观察者等行为型模式；抽象类提供通用骨架，用于模板方法、工厂方法等需复用流程与状态的模式；二者常组合使用，接口定协议、抽象类做默认实现。

接口和抽象类在设计模式中不是互相替代的关系，而是各司其职、常配合使用的两种抽象机制。关键不在“哪个更好”，而在“谁管契约、谁管骨架”。

接口负责定义能力契约，支撑策略、观察者、适配器等模式

接口天然适合表达“能做什么”，不绑定实现细节，因此是行为型和结构型模式的基石：

• 策略模式中，Strategy 接口统一声明算法执行方法（如 execute()），不同策略类（QuickSortStrategy、MergeSortStrategy）各自实现——调用方只依赖接口，随时切换算法
• 观察者模式里，Observer 接口约定 update() 方法签名，任何类只要实现它就能被主题通知，无关其具体类型
• 适配器模式中，目标接口（Target）定义客户端期望的行为，适配器类通过实现该接口 + 组合被适配对象，桥接不兼容的结构

抽象类提供通用骨架，是模板方法、工厂方法等模式的核心载体

抽象类擅长封装可复用流程与状态，把变与不变分离，典型用于创建型和行为型模式：

Alibabacloud Sdk Client Initialization For Java

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

下载

• 模板方法模式中，抽象类定义算法骨架（如 makeBeverage() 包含 boilWater()→brew()→pourInCup()），把 brew() 留为抽象方法由子类定制——咖啡和茶共用流程，只差一步冲泡逻辑
• 工厂方法模式里，抽象类（如 CreditCardFactory）声明创建产品的抽象方法 createCard()，并可能包含通用验证、日志等辅助逻辑；子类（GoldCardFactory）专注返回具体产品实例
• 抽象类还可预置公共字段（如配置、连接池引用）和构造器初始化逻辑，这是接口做不到的

二者常在同一模式中协同：接口定协议，抽象类做实现基座

真实项目中，两者经常分层配合，形成更健壮的设计：

• 比如命令模式：先定义 Command 接口（只有 execute()），保证所有命令可被统一调度；再提供 AbstractCommand 抽象类，封装日志记录、事务开启、重试逻辑等通用行为，具体命令类继承它并专注业务执行
• 又如支付系统：定义 PaymentProcessor 接口（pay()、refund()），确保所有渠道具备基础能力；再建 BasePaymentProcessor 抽象类，处理签名验签、幂等ID生成、异常统一封装，微信、支付宝等具体处理器继承它，只写差异化部分
• 这种组合既保留了接口的松耦合与多实现优势，又利用抽象类避免重复代码，比纯接口或纯抽象类都更贴近工程实际

选型判断有一条朴素原则：看你要抽象的是“能力”还是“身份”

不用背区别表，直接问自己两个问题：

• 这个抽象是否描述一类对象“**本质上是什么**”？比如“报表导出器”“数据库连接管理器”——它们有共同状态（数据源、格式配置）、固定流程（连接→查询→转换→写入），适合用抽象类
• 这个抽象是否描述一种“**跨类型都能做的事**”？比如“可撤销”“可序列化”“支持缓存”——飞机、文档、交易记录毫无继承关系，但都需要撤销操作，那就定义 Undoable 接口
• 当一个类既要体现某种身份（is-a），又要具备多种能力（has-a），就同时用：继承抽象类 + 实现多个接口

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南