陈易铭1. 从女儿国奇遇到代码世界：适配器模式的前世今生
记得第一次读《西游记》女儿国那段，最让我印象深刻的不是唐僧的定力，而是猪八戒那句"这国中都是女流，说的话俺老猪一句也听不懂"。当时就想，要是他们有个万能翻译器该多好。十几年后当我第一次接触适配器模式时，突然恍然大悟——这不就是代码世界的"万能翻译器"吗？
在Java开发中，我们经常会遇到类似女儿国语言障碍的场景：新系统要接入老接口、第三方库的API与现有代码不兼容、不同模块间的数据格式不一致...这些"语言不通"的问题，正是适配器模式大显身手的舞台。就像给唐僧团队配了个随身翻译，让原本无法直接沟通的双方能够顺畅协作。
适配器模式（Adapter Pattern）作为结构型设计模式的代表，其核心价值在于解决接口不兼容问题。它就像代码世界的"转接头"，让原本因为接口不匹配而无法一起工作的类可以协同工作。在实际项目中，这种场景比比皆是：
- 支付系统升级时新旧接口的过渡期
- 微服务架构中不同服务间的数据格式转换
- 遗留系统改造过程中新旧组件的共存
- 第三方SDK与自有框架的集成
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 适配器模式的三种形态与实现详解
2.1 类适配器：继承的力量
类适配器通过继承来实现适配，就像女儿国的翻译官继承了本国语言天赋又学习了外语。我们来看一个支付接口适配的典型例子：
java复制// 目标接口（期望的支付接口）
interface ModernPayment {
void pay(String orderId, double amount);
}
// 被适配的类（旧版支付实现）
class LegacyPayment {
public void processPayment(Map<String, Object> paymentData) {
// 旧版支付处理逻辑
}
}
// 类适配器
class PaymentAdapter extends LegacyPayment implements ModernPayment {
@Override
public void pay(String orderId, double amount) {
Map<String, Object> paymentData = new HashMap<>();
paymentData.put("orderId", orderId);
paymentData.put("amount", amount);
super.processPayment(paymentData);
}
}
这种方式的优点是实现直接，但缺点也很明显——Java不支持多重继承，如果被适配的类已经有父类，这种方法就不可行。我在电商项目迁移中就遇到过这种情况，最终选择了对象适配器方案。
2.2 对象适配器：组合的智慧
对象适配器采用组合方式，更符合"组合优于继承"的原则。继续以支付系统为例：
java复制class ObjectPaymentAdapter implements ModernPayment {
private LegacyPayment legacyPayment;
public ObjectPaymentAdapter(LegacyPayment legacyPayment) {
this.legacyPayment = legacyPayment;
}
@Override
public void pay(String orderId, double amount) {
Map<String, Object> paymentData = new HashMap<>();
paymentData.put("orderId", orderId);
paymentData.put("amount", amount);
legacyPayment.processPayment(paymentData);
}
}
这种方式更灵活，可以适配任意对象，也是实际开发中最常用的形式。在最近的一个金融项目中，我们就用对象适配器统一了五家不同银行的支付接口。
2.3 接口适配器：默认实现的妙用
接口适配器（又称缺省适配器）适用于需要实现一个大接口但只关心部分方法的情况。比如：
java复制interface BigInterface {
void method1();
void method2();
void method3();
// ...更多方法
}
abstract class InterfaceAdapter implements BigInterface {
@Override public void method1() {}
@Override public void method2() {}
@Override public void method3() {}
// 默认空实现
}
// 只需实现关心的方法
class MyAdapter extends InterfaceAdapter {
@Override public void method2() {
// 实际实现
}
}
这种模式在Swing事件监听器等场景中特别有用。我在开发一个UI框架时，就用它简化了事件处理的代码量。
3. 适配器模式在真实项目中的典型应用
3.1 日志框架适配：从Log4j到SLF4J
在日志框架统一过程中，适配器模式发挥了关键作用。比如我们需要将老项目的Log4j迁移到SLF4J：
java复制// 被适配的Log4j Logger
import org.apache.log4j.Logger;
// SLF4J适配器
public class Log4jToSlf4jAdapter implements org.slf4j.Logger {
private final Logger log4jLogger;
public Log4jToSlf4jAdapter(Logger log4jLogger) {
this.log4jLogger = log4jLogger;
}
@Override
public void info(String msg) {
log4jLogger.info(msg);
}
// 其他方法适配...
}
这种适配方式让我们可以逐步迁移，而不用一次性重写所有日志代码。在最近的一个微服务改造项目中，这种渐进式迁移策略帮我们节省了近30%的工作量。
3.2 数据格式转换：JSON与XML的和平共处
在API网关开发中，经常需要处理不同数据格式的转换。下面是一个JSON转XML的适配器示例：
java复制class JsonToXmlAdapter {
private final JsonService jsonService;
public JsonToXmlAdapter(JsonService jsonService) {
this.jsonService = jsonService;
}
public String getDataAsXml() {
String json = jsonService.getDataAsJson();
// 实现JSON到XML的转换逻辑
return convertJsonToXml(json);
}
private String convertJsonToXml(String json) {
// 实际转换实现
}
}
提示：在实际项目中，可以考虑使用Jackson或Gson等库来实现格式转换，而不是自己造轮子。
3.3 第三方SDK适配：统一不同云存储接口
当我们项目需要支持多家云存储时，适配器模式可以帮我们统一接口：
java复制interface CloudStorage {
void upload(String key, InputStream data);
InputStream download(String key);
}
// AWS S3适配器
class AwsS3Adapter implements CloudStorage {
private AmazonS3 s3Client;
@Override
public void upload(String key, InputStream data) {
s3Client.putObject("my-bucket", key, data, null);
}
// 其他方法实现...
}
// 阿里云OSS适配器
class AliOssAdapter implements CloudStorage {
private OSS ossClient;
@Override
public void upload(String key, InputStream data) {
ossClient.putObject("my-bucket", key, data);
}
// 其他方法实现...
}
这样业务代码只需要与CloudStorage接口交互，底层可以灵活切换不同的云服务提供商。在最近的一个跨云备份项目中，这种设计让我们轻松支持了AWS、阿里云和腾讯云三家服务。
4. 适配器模式的进阶技巧与实战经验
4.1 双向适配器：让沟通没有障碍
有时候我们需要两个不兼容的接口能够互相调用，这时就需要双向适配器。比如在消息系统整合时：
java复制class MessageAdapter implements NewMessageSystem, OldMessageSystem {
private NewMessageSystem newSystem;
private OldMessageSystem oldSystem;
// 实现两个接口的方法，在内部进行转换
@Override
public void sendNewFormat(NewMessage msg) {
OldMessage oldMsg = convertToOld(msg);
oldSystem.send(oldMsg);
}
@Override
public void sendOldFormat(OldMessage msg) {
NewMessage newMsg = convertToNew(msg);
newSystem.send(newMsg);
}
// 转换方法实现...
}
这种双向适配器在系统迁移过渡期特别有用，我在一个IM系统升级项目中使用后，实现了新旧版本客户端的无缝共存。
4.2 适配器与缓存结合：性能优化之道
当适配操作比较耗资源时，可以考虑加入缓存机制。比如在价格转换适配器中：
java复制class CachedCurrencyAdapter implements CurrencyConverter {
private final CurrencyConverter realConverter;
private final Map<String, Double> cache = new ConcurrentHashMap<>();
public CachedCurrencyAdapter(CurrencyConverter realConverter) {
this.realConverter = realConverter;
}
@Override
public double convert(double amount, String from, String to) {
String key = from + "->" + to;
return cache.computeIfAbsent(key,
k -> realConverter.convert(amount, from, to));
}
}
这种设计在跨国电商项目中帮我们减少了约40%的汇率查询API调用。
4.3 自动生成适配器：Lombok与注解的妙用
对于简单的适配场景，可以使用Lombok简化代码：
java复制@RequiredArgsConstructor
public class LombokAdapter implements NewInterface {
@NonNull
private final OldClass oldClass;
@Override
public void newMethod() {
// 自动委托给oldClass的对应方法
oldClass.oldMethod();
}
}
虽然这种方式不够灵活，但对于简单的委托场景能显著减少样板代码。我在维护一个老旧系统时，用这种方法快速创建了十几个适配器类。
5. 适配器模式的边界与替代方案
5.1 何时不该使用适配器模式
适配器模式虽好，但并非万能。以下情况可能需要考虑其他方案：
- 接口差异过大，适配成本高于重写成本
- 被适配的接口经常变动，导致适配器需要频繁修改
- 性能敏感场景，适配带来的间接调用成为瓶颈
在最近的一个高性能交易系统中，我们就因为适配器带来的微秒级延迟而选择了直接改造底层接口。
5.2 与其它模式的对比选择
- 桥接模式：关注抽象与实现的分离，而适配器关注接口转换
- 装饰器模式：增强功能而不改变接口，适配器则是转换接口
- 外观模式：简化复杂系统的接口，适配器是解决接口不匹配
在架构设计评审中，我经常看到团队混淆这些模式。一个简单的判断方法是：如果主要目的是让两个不兼容的接口能一起工作，那就是适配器模式的应用场景。
5.3 适配器模式在DDD中的特殊价值
在领域驱动设计中，适配器模式在防腐层（Anti-Corruption Layer）实现中扮演重要角色。比如：
java复制class ExternalSystemAdapter implements DomainService {
private final ExternalSystemClient client;
@Override
public DomainResult doSomething(DomainInput input) {
ExternalRequest request = convertToExternalRequest(input);
ExternalResponse response = client.callExternalApi(request);
return convertToDomainResult(response);
}
// 转换方法...
}
这种设计有效防止了外部系统的"腐败"影响到我们的核心领域模型。在一个供应链系统中，这种架构帮我们隔离了三家ERP系统的差异。