设计模式（七）结构型：适配器模式详解

设计模式（七）结构型：适配器模式详解

适配器模式（Adapter Pattern）是 GoF 23 种设计模式中的结构型模式之一，其核心价值在于将一个类的接口转换成客户端所期望的另一个接口，使得原本因接口不兼容而无法协同工作的类能够一起工作。它就像现实世界中的“电源转换插头”，解决了系统集成、遗留系统迁移、第三方库封装等场景中的接口不匹配问题。适配器模式是实现“开闭原则”和“依赖倒置原则”的关键工具，广泛应用于框架集成、API 封装、多数据源支持等架构设计中。

一、适配器模式详细介绍

适配器模式解决的是“接口不兼容”的集成难题。在大型系统演进过程中，常需引入新组件、替换旧服务或集成第三方系统，但这些外部组件的接口往往与当前系统的期望接口不一致。直接修改客户端代码或外部组件通常成本高、风险大。适配器模式通过引入一个“中间层”——适配器，将不兼容的接口进行转换，使系统各部分能够无缝协作。

该模式涉及以下核心角色：

• Target（目标接口）：客户端所期望的接口，通常是系统内部定义的标准接口。
• Adaptee（被适配者）：已存在的、但接口不兼容的类或服务，通常是外部系统、遗留组件或第三方库。
• Adapter（适配器）：实现 Target 接口，并持有对 Adaptee 的引用。它在内部将 Target 的请求转换为对 Adaptee 的调用，完成接口转换。
• Client（客户端）：只依赖 Target 接口，无需知道 Adaptee 的存在，通过适配器间接使用被适配者的服务。

适配器模式有两种主要实现方式：

1. 类适配器（Class Adapter）：通过多重继承实现，Adapter 同时继承 Adaptee 并实现 Target 接口。由于 Java 不支持多继承，此方式在 Java 中受限，通常使用组合替代。
2. 对象适配器（Object Adapter）：通过对象组合实现，Adapter 持有一个 Adaptee 的实例，并在方法中委托调用。这是 Java 中最常用的方式，符合“合成复用原则”。

适配器模式的关键优势在于：

• 解耦客户端与具体实现：客户端只依赖目标接口，不依赖被适配者的具体类。
• 复用现有代码：无需修改 Adaptee 或客户端代码，即可实现集成。
• 支持开闭原则：新增适配器即可支持新的外部服务，无需修改现有逻辑。
• 封装复杂性：将接口转换逻辑集中于适配器中，简化客户端使用。

与“装饰器模式”相比，适配器关注接口转换，而装饰器关注功能增强；与“代理模式”相比，适配器改变接口，代理保持接口不变但控制访问。

二、适配器模式的UML表示

以下是适配器模式的标准 UML 类图（以对象适配器为例）：

图解说明：

• Target 是客户端期望的接口，定义 request() 方法。
• Adaptee 是已存在的类，提供 specificRequest() 方法，但接口不匹配。
• Adapter 实现 Target 接口，并持有一个 Adaptee 实例。在 request() 方法中调用 adaptee.specificRequest()。
• Client 仅依赖 Target，通过多态调用 request()，实际执行的是适配后的逻辑。

三、一个简单的Java程序实例

以下是一个模拟支付系统集成的 Java 示例，展示如何使用适配器模式集成一个不兼容的第三方支付服务。

// 目标接口：系统期望的支付接口
interface PaymentProcessor {void pay(double amount);void refund(double amount);
}// 被适配者：第三方支付服务（接口不兼容）
class ThirdPartyPaymentGateway {public void executePayment(String currency, double value) {System.out.println("ThirdPartyPaymentGateway: Processing " + value + " " + currency);}public void initiateRefund(String currency, double value) {System.out.println("ThirdPartyPaymentGateway: Refunding " + value + " " + currency);}
}// 适配器：将第三方网关适配为系统标准接口
class PaymentGatewayAdapter implements PaymentProcessor {private ThirdPartyPaymentGateway gateway;private String currency; // 假设系统默认使用 USDpublic PaymentGatewayAdapter(ThirdPartyPaymentGateway gateway, String currency) {this.gateway = gateway;this.currency = currency;}@Overridepublic void pay(double amount) {// 将标准 pay 调用转换为第三方 executePayment 调用gateway.executePayment(currency, amount);}@Overridepublic void refund(double amount) {// 将标准 refund 调用转换为第三方 initiateRefund 调用gateway.initiateRefund(currency, amount);}
}// 客户端：订单服务
class OrderService {private PaymentProcessor paymentProcessor;public OrderService(PaymentProcessor paymentProcessor) {this.paymentProcessor = paymentProcessor;}public void processOrder(double amount) {System.out.println("OrderService: Processing order for $" + amount);paymentProcessor.pay(amount);System.out.println("OrderService: Order processed successfully.");}public void cancelOrder(double refundAmount) {System.out.println("OrderService: Cancelling order, refunding $" + refundAmount);paymentProcessor.refund(refundAmount);System.out.println("OrderService: Refund initiated.");}
}// 客户端使用示例
public class AdapterPatternDemo {public static void main(String[] args) {// 创建被适配者实例ThirdPartyPaymentGateway thirdPartyGateway = new ThirdPartyPaymentGateway();// 创建适配器，将第三方网关适配为系统接口PaymentProcessor adapter = new PaymentGatewayAdapter(thirdPartyGateway, "USD");// 客户端（订单服务）只依赖 PaymentProcessor 接口OrderService orderService = new OrderService(adapter);// 客户端无需知道底层是哪个支付服务，调用标准接口orderService.processOrder(99.99);System.out.println();orderService.cancelOrder(49.99);}
}

运行说明：

• OrderService 是客户端，只依赖 PaymentProcessor 接口。
• ThirdPartyPaymentGateway 是外部服务，接口为 executePayment 和 initiateRefund，不兼容。
• PaymentGatewayAdapter 实现 PaymentProcessor，内部调用 ThirdPartyPaymentGateway 的方法，完成参数和语义转换。
• 客户端代码完全 unaware 第三方服务的存在，实现了松耦合。

四、总结

特性	说明
核心目的	解决接口不兼容问题，实现系统集成
实现方式	对象适配器（推荐）、类适配器（受限）
关键机制	接口转换、委托调用（Delegation）
优点	解耦、复用、支持开闭原则、封装集成复杂性
缺点	增加类数量、过度使用可能导致系统复杂
适用场景	集成第三方库、迁移遗留系统、多数据源适配、API 封装

适配器模式应谨慎使用：

• 不应将适配器用于本应统一设计的内部模块。
• 避免“适配器链”过长，导致调用路径复杂。
• 适配器应尽量保持轻量，仅做接口转换，不包含业务逻辑。

架构师洞见：
适配器模式是系统“可集成性”与“可演化性”的基石。在微服务架构中，它被广泛用于网关层协议转换（如 gRPC 转 HTTP）、数据格式适配（如 XML 转 JSON）、多云服务抽象（如统一 AWS/S3 与 Azure Blob Storage 接口）。架构师应认识到：适配器不仅是技术工具，更是边界划分的体现——它清晰地标识了系统内部标准与外部异构实现之间的分界线。

未来趋势是：适配器模式将与服务网格（Service Mesh）、API 网关、事件驱动架构深度融合。例如，在事件总线中，适配器可将不同来源的事件格式统一为标准事件结构；在 Serverless 平台中，适配器可将云函数接口适配为传统 Web API。

掌握适配器模式，有助于设计出高内聚、低耦合、易扩展的系统。作为架构师，应倡导在系统边界（如防腐层 Anti-Corruption Layer）使用适配器，隔离外部变化，保护核心领域模型。同时，应避免滥用适配器掩盖设计缺陷，确保内部模块遵循统一契约。适配器是“集成的艺术”，更是“架构的智慧”。