1. 适配器模式概述
适配器模式（Adapter Pattern）是结构型设计模式中最常用的模式之一，它就像现实生活中的电源适配器一样，能够让原本不兼容的接口协同工作。我在实际开发中经常遇到这样的场景：新系统需要整合遗留代码，但两者的接口规范不一致，这时候适配器模式就能大显身手。
这个模式的本质是创建一个中间层，通过包装（wrap）已有的类，提供客户端期望的接口。就像Type-C转3.5mm耳机转接头，它不改变耳机和手机的功能，只是让两者能够连接。适配器模式主要解决"接口不兼容"的问题，属于"亡羊补牢"式的解决方案——理想情况下我们应该设计统一的接口规范，但在实际项目中，接口不一致的情况比比皆是。
2. 适配器模式的核心结构
2.1 类适配器 vs 对象适配器
适配器模式有两种主要实现方式：
类适配器（通过继承实现）
java复制// 目标接口
interface Target {
void request();
}
// 被适配者
class Adaptee {
public void specificRequest() {
System.out.println("特殊请求");
}
}
// 适配器
class Adapter extends Adaptee implements Target {
@Override
public void request() {
specificRequest(); // 调用父类方法
}
}
对象适配器（通过组合实现）
java复制class Adapter implements Target {
private Adaptee adaptee;
public Adapter(Adaptee adaptee) {
this.adaptee = adaptee;
}
@Override
public void request() {
adaptee.specificRequest();
}
}
实际开发中更推荐使用对象适配器，因为它符合组合优于继承的原则，且一个适配器可以适配多个不同的被适配者。
2.2 模式参与者
- Target（目标接口）：客户端期望的接口
- Adaptee（被适配者）：需要被适配的现有类
- Adapter（适配器）：将Adaptee接口转换为Target接口
3. 适配器模式的典型应用场景
3.1 旧系统整合
我在金融项目中遇到过这样的案例：新交易系统需要接入老的核心账务系统，但两者的接口规范完全不同。老系统使用SOAP协议，新系统采用RESTful API。我们开发了一组适配器，将REST调用转换为SOAP调用，避免了重写老系统的风险。
3.2 第三方库适配
不同日志框架（如Log4j和SLF4J）之间的桥接就是典型的适配器应用。SLF4J作为门面，底层通过适配器支持多种日志实现，让业务代码无需关心具体日志实现。
3.3 数据格式转换
JSON和XML之间的转换器也是适配器模式的体现。例如：
java复制interface DataParser {
String parseToJson(String data);
}
class XmlToJsonAdapter implements DataParser {
private XmlParser xmlParser;
@Override
public String parseToJson(String xmlData) {
// 调用xmlParser处理，然后转换为json
return convertXmlToJson(xmlParser.parse(xmlData));
}
}
4. 适配器模式的实现细节
4.1 实现注意事项
- 接口设计：适配器接口应尽量保持简单，避免引入过多转换逻辑
- 性能考量：频繁调用的适配器要考虑缓存机制
- 错误处理：明确区分是适配器错误还是被适配对象错误
4.2 Spring中的适配器案例
Spring MVC的HandlerAdapter是经典实现：
java复制public interface HandlerAdapter {
boolean supports(Object handler);
ModelAndView handle(HttpServletRequest request,
HttpServletResponse response,
Object handler) throws Exception;
}
// 对Controller接口的适配
public class SimpleControllerHandlerAdapter implements HandlerAdapter {
public boolean supports(Object handler) {
return (handler instanceof Controller);
}
public ModelAndView handle(HttpServletRequest request,
HttpServletResponse response,
Object handler) throws Exception {
return ((Controller) handler).handleRequest(request, response);
}
}
5. 适配器模式的优缺点分析
5.1 优势
- 解耦客户端与被适配者：客户端只依赖目标接口
- 复用现有类：无需修改原有代码就能整合功能
- 灵活扩展：可以随时增加新的适配器
5.2 局限性
- 过度使用会导致系统复杂：如果接口本来可以统一，强行使用适配器会增加维护成本
- 性能损耗：多一层调用会有轻微性能影响
6. 适配器模式的最佳实践
6.1 与其他模式的关系
- 与外观模式：适配器主要解决接口转换，外观模式简化复杂系统
- 与装饰器模式：适配器改变接口，装饰器增强功能
- 与代理模式：适配器重在转换，代理重在控制访问
6.2 实战建议
- 优先考虑对象适配器（组合方式）
- 为适配器编写单元测试，确保转换逻辑正确
- 在适配器命名上体现其用途，如"XmlToJsonAdapter"
- 考虑使用依赖注入框架管理适配器实例
7. 常见问题排查
7.1 适配器不工作
可能原因：
- 被适配对象未正确初始化
- 接口方法不匹配
- 类型转换异常
排查步骤：
- 检查适配器的supports()方法
- 验证方法签名是否一致
- 添加日志记录输入输出
7.2 性能问题
优化方案：
- 缓存频繁调用的结果
- 使用对象池复用适配器实例
- 考虑异步处理
8. 真实项目案例
8.1 支付网关整合
某电商平台需要同时支持支付宝、微信支付和银联支付，各支付渠道接口差异很大。我们设计了如下结构：
java复制// 统一支付接口
interface PaymentService {
PaymentResult pay(PaymentRequest request);
}
// 支付宝适配器
class AlipayAdapter implements PaymentService {
private AlipayService alipay;
public PaymentResult pay(PaymentRequest request) {
AlipayRequest aliReq = convertRequest(request);
AlipayResponse resp = alipay.pay(aliReq);
return convertResponse(resp);
}
}
8.2 数据库驱动适配
JDBC本身就是适配器模式的典型应用，不同的数据库驱动（MySQL、Oracle等）都适配统一的JDBC接口。
9. 扩展思考
9.1 双向适配器
某些场景需要双向转换，可以设计双向适配器：
java复制class BiAdapter implements NewInterface, OldInterface {
// 实现两个接口的转换逻辑
}
9.2 自动化适配器生成
对于简单的接口转换，可以考虑使用代码生成工具自动创建适配器类，减少重复劳动。例如通过注解处理器：
java复制@GenerateAdapter(from = OldService.class, to = NewInterface.class)
public class AutoGeneratedAdapter {
// 自动生成的适配代码
}
在实际项目中，适配器模式往往不是单独存在的，通常会结合工厂模式创建适配器实例，或者与门面模式配合使用。理解适配器的本质是"转换"而非"创造"，就能在恰当的场合发挥它的价值。