适配器模式实战：接口兼容与系统解耦

1. 适配器模式：隔离变化的瑞士军刀

第一次接触适配器模式是在2015年维护一个老旧的支付系统时。系统需要接入新的第三方支付渠道，但新接口与原有架构格格不入。当我尝试直接修改核心业务逻辑时，项目经理拍桌怒吼："你知不知道这些代码有多少下游依赖？！"那一刻，我真正理解了"隔离变化"的价值。

适配器模式（Adapter Pattern）就像电子设备中的物理适配器——让Type-C接口的硬盘能在USB-A的电脑上读写数据。在软件设计中，它通过包装（wrapper）的方式，将一个类的接口转换成客户端期望的另一个接口，使原本因接口不兼容而不能一起工作的类可以协同工作。这种模式属于结构型设计模式，与装饰器、代理模式同宗但不同用。

关键认知：适配器不是为了让系统"能工作"，而是为了让变化"不扩散"。它的核心价值在于将易变部分与稳定部分隔离，控制修改范围。

2. 适配器模式的三种实现形态

2.1 类适配器：继承的力量与局限

通过多重继承实现适配是最直观的方式。假设我们有一个老旧的日志接口：

java复制public class LegacyLogger {
    public void logToFile(String message) {
        // 写入本地文件的复杂逻辑
    }
}

现在需要适配新的日志标准接口：

java复制public interface ModernLogger {
    void log(String message, LogLevel level);
}

类适配器的实现：

java复制public class LoggerAdapter extends LegacyLogger implements ModernLogger {
    @Override
    public void log(String message, LogLevel level) {
        // 将level转换为旧版需要的格式
        String formatted = "[" + level + "] " + message;
        super.logToFile(formatted);
    }
}

实战陷阱：

• Java等单继承语言中，若被适配者已是具体类，此法不可行
• 容易造成方法污染（如LegacyLogger的其他方法也被暴露）
• 2021年我在金融项目中因此导致过安全漏洞——适配器意外暴露了父类的敏感方法

2.2 对象适配器：组合优于继承

更推荐的实现方式是通过组合：

java复制public class LoggerAdapter implements ModernLogger {
    private final LegacyLogger legacyLogger;

    public LoggerAdapter(LegacyLogger logger) {
        this.legacyLogger = logger;
    }

    @Override
    public void log(String message, LogLevel level) {
        String formatted = formatMessage(message, level);
        legacyLogger.logToFile(formatted);
    }

    private String formatMessage(String msg, LogLevel level) {
        return String.format("[%s][%s] %s", 
            LocalDateTime.now(), level, msg);
    }
}

优势对比：

2.3 接口适配器：JDK8的默认方法

Java 8之后出现了一种特殊形态：

java复制public interface ModernLogger {
    default void log(String message, LogLevel level) {
        System.out.printf("[%s] %s\n", level, message);
    }
}

// 使用时只需实现需要的方法
new ModernLogger() {}.log("test", LogLevel.INFO);

这种"缺省适配器"适合SDK设计，我在开发物联网平台时常用它来提供可选功能的基础实现。

3. 真实场景中的适配器实践

3.1 支付系统改造案例

2020年某电商平台升级时，需要兼容以下支付方式：

• 旧版：基于XML的SOAP接口
• 新版：RESTful JSON接口

解决方案架构：

code复制[支付核心逻辑] ← 统一接口 → [SOAP适配器] → 旧支付网关
                      ↓
               [JSON适配器] → 新支付网关

关键代码片段：

java复制// 统一业务接口
public interface PaymentService {
    PaymentResult pay(PaymentRequest request);
}

// SOAP适配器
public class SoapPaymentAdapter implements PaymentService {
    private final OldSoapClient client;

    public SoapPaymentAdapter(OldSoapClient client) {
        this.client = client;
    }

    @Override
    public PaymentResult pay(PaymentRequest request) {
        SoapEnvelope envelope = convertToSoap(request);
        SoapResponse response = client.sendPayment(envelope);
        return convertToDomain(response);
    }
    // 省略转换方法...
}

性能优化点：

• 使用对象池管理SOAP连接（避免每次创建开销）
• 引入缓存加速XML-Java对象转换
• 异步记录适配日志（不影响主流程）

3.2 跨平台UI适配难题

在2022年的跨端编辑器项目中，我们需要让React组件在Native环境中运行。通过设计一个通用的UI适配器接口：

typescript复制interface NativeUIAdapter {
    createButton(config: ButtonConfig): NativeButton;
    createInput(config: InputConfig): NativeInput;
    // ...
}

// 安卓实现
class AndroidUIAdapter implements NativeUIAdapter {
    createButton(config) {
        return new AndroidButton(config.text);
    }
}

// React包装层
function useNativeComponent(type, config) {
    const adapter = useContext(NativeAdapterContext);
    return adapter[`create${type}`](config);
}

踩坑记录：

1. 事件机制差异：Web的冒泡机制与Native的直传机制
   • 解决方案：在适配层统一实现事件代理
2. 样式隔离问题：CSS-in-JS与平台样式表的冲突
   • 最终采用：将样式转换为平台特定表达

4. 适配器模式的进阶思考

4.1 与其它模式的联用

装饰器+适配器组合：
在微服务认证场景中，我们曾这样设计：

java复制// 基础功能
interface AuthService {
    Token authenticate(Credentials creds);
}

// 适配不同供应商
class VendorAAuthAdapter implements AuthService {
    private final VendorAClient client;
    // 实现适配逻辑...
}

// 添加缓存装饰
class CachingAuthDecorator implements AuthService {
    private final AuthService wrapped;
    private final Cache cache;

    @Override
    public Token authenticate(Credentials creds) {
        return cache.computeIfAbsent(creds.key(), 
            k -> wrapped.authenticate(creds));
    }
}

模式对比表：

4.2 过度适配的反模式

在2018年的CRM系统重构中，我们犯过一个典型错误：

java复制// 过度设计的抽象
interface DataSource {
    Result query(Query query);
}

// 为每个旧DAO类创建适配器
class UserDaoAdapter implements DataSource {
    private final LegacyUserDao dao;
    // 数十个方法适配...
}

问题诊断：

• 适配层本身成为维护负担
• 调用链路过深导致性能下降
• 违反了"适配器应当轻薄"的原则

修正方案：

1. 识别真正的变化点，仅适配必要接口
2. 采用"批量适配"策略，合并相似操作
3. 通过代码生成减少手工工作量

5. 现代语言中的适配器演进

5.1 Kotlin的扩展函数适配

在Android开发中，可以用扩展函数实现轻量适配：

kotlin复制// 旧版Java类
class LegacySensor {
    fun getValue(): FloatArray = ...
}

// 适配扩展
fun LegacySensor.asModernSensor(): ModernSensor {
    return object : ModernSensor {
        override fun read(): SensorData {
            val values = this@asModernSensor.getValue()
            return SensorData(values[0], values[1])
        }
    }
}

5.2 TypeScript的类型适配

处理第三方库类型不匹配时：

typescript复制// 库提供的类型
interface LibUser {
    id_str: string;
    full_name: string;
}

// 我们的领域类型
interface User {
    id: number;
    name: string;
}

// 类型适配器
const adaptUser = (libUser: LibUser): User => ({
    id: parseInt(libUser.id_str),
    name: libUser.full_name
});

自动类型推导技巧：

typescript复制type Adapter<TFrom, TTo> = (source: TFrom) => TTo;

function createAdapter<TFrom, TTo>(
    adapter: Adapter<TFrom, TTo>
): Adapter<TFrom, TTo> {
    return adapter;
}

// 使用时会自动推断类型
const userAdapter = createAdapter(adaptUser);

6. 测试适配器的实用技巧

6.1 隔离测试策略

测试金字塔应用：

code复制       [业务逻辑测试]
          /     \
[适配器接口测试]  [被适配方测试]

示例测试用例（JUnit5）：

java复制class PaymentAdapterTest {
    private LegacyPaymentSystem mockLegacy;
    private PaymentAdapter adapter;

    @BeforeEach
    void setup() {
        mockLegacy = mock(LegacyPaymentSystem.class);
        adapter = new PaymentAdapter(mockLegacy);
    }

    @Test
    void shouldConvertCurrency() {
        when(mockLegacy.process(any())).thenReturn(
            new LegacyResponse("USD", "100.00"));
        
        ModernResponse response = adapter.pay(
            new ModernRequest("EUR", "120.00"));
            
        assertEquals("USD", response.currency());
        assertTrue(response.amount() > 100);
    }
}

6.2 契约测试实践

使用Pact进行接口契约验证：

java复制// 消费者端测试
@PactTest
void testPaymentAdapter(PactBuilder builder) {
    builder
        .consumer("ModernSystem")
        .hasPactWith("LegacySystem")
        .given("a valid account")
        .uponReceiving("payment request")
        .path("/pay")
        .method("POST")
        .body(new JsonBody(new {
            amount = 100.00,
            currency = "USD"
        }))
        .willRespondWith()
        .status(200)
        .body(new JsonBody(new {
            code = "SUCCESS",
            transactionId = "txn_123"
        }));

    // 验证适配器能处理此响应
    LegacyClient client = new LegacyClient(builder.getMockServerUrl());
    PaymentAdapter adapter = new PaymentAdapter(client);
    PaymentResult result = adapter.pay(new Payment(100, "USD"));
    assertNotNull(result.getTransactionId());
}

7. 性能优化关键点

7.1 对象创建开销

在2023年的高频交易系统中，我们发现适配器对象创建消耗了15%的CPU时间。通过以下优化方案将损耗降至3%：

1. 对象池化：

java复制public class AdapterPool {
    private final Queue<PaymentAdapter> pool = new ConcurrentLinkedQueue<>();

    public PaymentAdapter borrowAdapter() {
        PaymentAdapter adapter = pool.poll();
        return adapter != null ? adapter : new PaymentAdapter();
    }

    public void returnAdapter(PaymentAdapter adapter) {
        adapter.reset(); // 清理状态
        pool.offer(adapter);
    }
}

2. 缓存转换结果：

java复制class CachingAdapter {
    private final Cache<RequestKey, Response> cache;

    public Response adapt(Request request) {
        return cache.computeIfAbsent(
            request.key(),
            k -> doActualAdaptation(request)
        );
    }
}

7.2 异步适配模式

处理慢速遗留系统时采用的模式：

java复制public class AsyncPaymentAdapter {
    private final Executor executor;
    private final LegacyPaymentService legacy;

    public CompletableFuture<ModernResult> payAsync(ModernRequest request) {
        return CompletableFuture.supplyAsync(() -> {
            LegacyRequest legacyReq = convertRequest(request);
            LegacyResponse legacyResp = legacy.process(legacyReq);
            return convertResponse(legacyResp);
        }, executor);
    }
}

线程池配置建议：

• 核心线程数 = 遗留系统QPS × 平均响应时间(秒)
• 队列容量 = 核心线程数 × 3
• 使用有界队列防止内存溢出

8. 何时不用适配器

经过多个项目的教训，这些情况应避免使用适配器：

1. 接口差异过大时
   当两个系统的领域模型根本不同（如订单系统适配库存系统），应考虑：

   • 引入中间领域模型
   • 使用防腐层(Anti-Corruption Layer)

2. 临时解决方案
   如果只是短期过渡，更推荐：

   • 包装门面(Facade)
   • 直接修改客户端代码

3. 性能敏感场景
   在每秒万级调用的系统中，每层适配都会带来：

   • 2~5微秒的方法调用开销
   • 额外的内存分配压力

一个判断标准：如果适配器代码量超过被适配类的50%，很可能选错了方案。