1. 适配器模式初探：连接不兼容世界的桥梁
在软件开发中，我们经常会遇到这样的场景：新系统需要与遗留系统对接，或者第三方库的接口与我们的预期不符。就像旅行时带着欧标插头的电器来到英国，面对形状迥异的插座，我们需要一个转接头才能正常使用——这就是适配器模式（Adapter Pattern）在现实生活中的完美体现。
作为结构型设计模式中的"和事佬"，适配器模式的核心价值在于：让原本由于接口不兼容而不能一起工作的类能够协同工作。它通过创建一个中间层来转换接口，使得客户端可以以统一的方式调用不同接口的对象。这种模式在实际开发中应用极为广泛，从数据库驱动到UI组件库，从支付接口到日志系统，几乎无处不在。
2. 适配器模式的结构解析
2.1 类适配器与对象适配器
适配器模式主要有两种实现方式：
类适配器（继承方式）
// 目标接口（客户端期望的接口） interface Target { void request(); } // 被适配者（需要适配的现有类） class Adaptee { public void specificRequest() { System.out.println("特殊请求处理"); } } // 适配器（通过继承实现） class ClassAdapter extends Adaptee implements Target { @Override public void request() { specificRequest(); // 将目标接口转换为被适配者接口 } }对象适配器（组合方式）
class ObjectAdapter implements Target { private Adaptee adaptee; public ObjectAdapter(Adaptee adaptee) { this.adaptee = adaptee; } @Override public void request() { adaptee.specificRequest(); } }两种实现方式的对比：
| 特性 | 类适配器 | 对象适配器 |
|---|---|---|
| 实现方式 | 继承被适配类 | 组合被适配类对象 |
| 灵活性 | 较低（静态关系） | 较高（运行时可替换） |
| 适用场景 | 适配单一类 | 适配类及其子类 |
| 代码耦合度 | 较高 | 较低 |
提示：现代编程更推荐使用对象适配器，因为它遵循了"组合优于继承"的原则，且能适配整个类层次结构。
2.2 适配器模式的参与者角色
Target（目标接口）：客户端期望的接口，定义了客户端需要使用的特定领域接口。
Adaptee（被适配者）：已经存在的接口，需要被适配的类，通常包含一些有用的功能。
Adapter（适配器）：对Adaptee的接口进行适配，使其符合Target接口的要求。
3. 适配器模式的典型应用场景
3.1 遗留系统集成
在系统升级过程中，我们经常需要让新代码与遗留代码协同工作。例如，公司原有的用户认证系统使用XML格式传输数据，而新系统采用JSON格式：
// 旧系统接口 class LegacyAuthService { public String getUserInfoXml(String userId) { return "<user><id>"+userId+"</id><name>张三</name></user>"; } } // 新系统期望的接口 interface ModernAuthService { JSONObject getUserInfoJson(String userId); } // 适配器实现 class AuthAdapter implements ModernAuthService { private LegacyAuthService legacyService; public AuthAdapter(LegacyAuthService service) { this.legacyService = service; } @Override public JSONObject getUserInfoJson(String userId) { String xml = legacyService.getUserInfoXml(userId); return XML.toJSONObject(xml); // 转换XML到JSON } }3.2 第三方库适配
不同日志框架的API差异很大，使用适配器模式可以统一日志接口：
// 统一的日志接口 interface Logger { void log(String level, String message); } // Log4j适配器 class Log4jAdapter implements Logger { private org.apache.log4j.Logger log4j; public Log4jAdapter(Class<?> clazz) { this.log4j = org.apache.log4j.Logger.getLogger(clazz); } @Override public void log(String level, String message) { switch(level.toLowerCase()) { case "debug": log4j.debug(message); break; case "info": log4j.info(message); break; // 其他级别处理... } } }3.3 接口版本兼容
当API升级导致接口不兼容时，可以使用适配器保持向后兼容：
// 新版本接口 interface NewPaymentService { PaymentResult pay(String orderId, BigDecimal amount, PaymentMethod method); } // 旧版本适配器 class OldPaymentAdapter implements NewPaymentService { private OldPaymentService oldService; public PaymentResult pay(String orderId, BigDecimal amount, PaymentMethod method) { // 将新接口参数转换为旧接口格式 String oldMethod = convertPaymentMethod(method); String result = oldService.processPayment(orderId, amount.toString(), oldMethod); return parseOldResult(result); } // 转换方法省略... }4. 适配器模式的实现技巧与最佳实践
4.1 实现注意事项
接口最小化适配：只适配真正需要的方法，不要盲目实现整个接口。对于不需要的方法可以抛出UnsupportedOperationException。
保持单一职责：一个适配器应该只负责一个特定接口的转换，避免创建"万能适配器"。
考虑线程安全：如果被适配对象不是线程安全的，需要在适配器中添加同步机制。
性能考量：频繁调用的适配器可能需要考虑缓存策略，避免重复转换开销。
4.2 与其他模式的关系
桥接模式：都是连接不同部分的模式，但桥接模式关注的是抽象和实现的分离，而适配器关注的是接口转换。
装饰器模式：都可以包装对象，但装饰器是为了增强功能，适配器是为了转换接口。
外观模式：都是对复杂系统的简化，但外观模式定义的是新接口，适配器是复用现有接口。
5. 实战案例：支付网关统一适配
假设我们需要集成多个支付渠道（支付宝、微信、银联），各渠道接口差异很大：
// 统一支付接口 interface UnifiedPayment { boolean pay(Order order); boolean refund(Order order); PaymentStatus checkStatus(String orderId); } // 支付宝适配器 class AlipayAdapter implements UnifiedPayment { private AlipayService alipay; public boolean pay(Order order) { AlipayRequest request = new AlipayRequest(); request.setOutTradeNo(order.getId()); request.setTotalAmount(order.getAmount()); // 其他字段转换... AlipayResponse response = alipay.tradePay(request); return response.isSuccess(); } // 其他方法实现... } // 微信支付适配器 class WechatpayAdapter implements UnifiedPayment { private WechatPayService wechatPay; public boolean pay(Order order) { WechatPayUnifiedOrderRequest request = new WechatPayUnifiedOrderRequest(); request.setOutTradeNo(order.getId()); request.setTotalFee(order.getAmount().multiply(100).intValue()); // 其他字段转换... return wechatPay.unifiedOrder(request).isSuccess(); } // 其他方法实现... }在这个案例中，适配器模式带来了以下优势：
- 业务代码只需面向统一的UnifiedPayment��口编程
- 新增支付渠道只需添加新的适配器，不影响现有代码
- 各支付渠道的特殊处理被封装在适配器中
- 便于单元测试和模拟
6. 适配器模式的局限性与替代方案
虽然适配器模式非常实用，但也有其局限性：
过度使用会导致系统复杂：如果系统中适配器过多，会使得代码难以理解和维护。
性能开销：额外的间接调用会带来一定的性能损耗，对性能敏感的场景需要谨慎。
设计警示：如果需要大量使用适配器，可能意味着系统接口设计存在问题。
替代方案考虑：
- 如果可能，直接修改接口使其保持一致
- 使用外观模式提供更高级别的统一接口
- 对于简单转换，可以使用静态工具类方法
我在实际项目中使用适配器模式的经验是：对于短期集成方案或无法修改的第三方接口，适配器是很好的解决方案；但对于长期维护的核心系统，应该考虑重构接口设计，减少对适配器的依赖。
