适配器模式：让接口兼容变得简单高效

一、适配器模式的核心概念与价值

适配器模式（Adapter Pattern）是一种结构型设计模式，其核心目标是通过一个中间层（适配器）将不兼容的接口转换为客户端期望的接口，从而解决接口不匹配导致的代码耦合问题。在软件开发中，适配器模式类似于现实生活中的“电源转换器”——将不同国家的插座接口统一为可用的标准接口，避免因硬件差异导致的兼容性问题。

从技术价值来看，适配器模式具有以下优势：

1. 解耦系统依赖：通过适配器隔离客户端与目标接口的直接交互，降低系统间的耦合度。
2. 提升代码复用性：允许将现有类或第三方库的接口适配到项目需求中，避免重复开发。
3. 支持渐进式重构：在旧系统升级或替换组件时，适配器可作为过渡层，平滑迁移功能。

二、适配器模式的实现方式与代码示例

适配器模式可分为类适配器（通过继承实现）和对象适配器（通过组合实现）两种类型。以下通过具体代码示例说明其实现方式。

1. 类适配器实现（基于继承）

// 目标接口（客户端期望的接口）
interface Target {
    void request();
}
// 被适配者（现有不兼容的接口）
class Adaptee {
    public void specificRequest() {
        System.out.println("Adaptee's specificRequest");
    }
}
// 类适配器（继承Adaptee并实现Target）
class ClassAdapter extends Adaptee implements Target {
    @Override
    public void request() {
        specificRequest(); // 调用被适配者的方法
    }
}
// 客户端调用
public class Client {
    public static void main(String[] args) {
        Target target = new ClassAdapter();
        target.request(); // 输出：Adaptee's specificRequest
    }
}

适用场景：当被适配者是单一类且需要重用其部分功能时，类适配器可通过继承直接扩展。但Java不支持多继承，可能限制灵活性。

2. 对象适配器实现（基于组合）

// 对象适配器（组合Adaptee并实现Target）
class ObjectAdapter implements Target {
    private Adaptee adaptee;
    public ObjectAdapter(Adaptee adaptee) {
        this.adaptee = adaptee;
    }
    @Override
    public void request() {
        adaptee.specificRequest(); // 委托给被适配者
    }
}
// 客户端调用
public class Client {
    public static void main(String[] args) {
        Target target = new ObjectAdapter(new Adaptee());
        target.request(); // 输出：Adaptee's specificRequest
    }
}

适用场景：对象适配器通过组合方式适配被适配者，更符合“组合优于继承”的原则，支持适配多个被适配者或动态切换实现。

三、适配器模式的应用场景与实战案例

1. 整合第三方库的接口

案例背景：项目中使用一个旧版日志库（LegacyLogger），其接口方法为log(String message)，而新架构要求统一使用Logger接口的info(String message)方法。

解决方案：

interface Logger {
    void info(String message);
}
class LegacyLogger {
    public void log(String message) {
        System.out.println("Legacy Log: " + message);
    }
}
class LoggerAdapter implements Logger {
    private LegacyLogger legacyLogger;
    public LoggerAdapter(LegacyLogger legacyLogger) {
        this.legacyLogger = legacyLogger;
    }
    @Override
    public void info(String message) {
        legacyLogger.log(message); // 适配旧接口
    }
}
// 客户端使用
public class Client {
    public static void main(String[] args) {
        Logger logger = new LoggerAdapter(new LegacyLogger());
        logger.info("System started"); // 输出：Legacy Log: System started
    }
}

价值体现：通过适配器，无需修改现有日志库代码即可满足新架构需求，降低迁移成本。

2. 跨系统数据格式转换

案例背景：支付系统需要同时支持XML和JSON格式的请求，但核心处理逻辑仅能处理JSON。

解决方案：

interface PaymentRequest {
    String getContent();
}
class JsonRequest implements PaymentRequest {
    private String json;
    public JsonRequest(String json) {
        this.json = json;
    }
    @Override
    public String getContent() {
        return json;
    }
}
class XmlRequestAdapter implements PaymentRequest {
    private String xml;
    public XmlRequestAdapter(String xml) {
        this.xml = xml;
    }
    @Override
    public String getContent() {
        // 模拟XML转JSON的逻辑
        return convertXmlToJson(xml);
    }
    private String convertXmlToJson(String xml) {
        return "{\"converted\":\"" + xml.replace("<", "").replace(">", "") + "\"}";
    }
}
// 客户端调用
public class Client {
    public static void main(String[] args) {
        PaymentRequest jsonRequest = new JsonRequest("{\"key\":\"value\"}");
        PaymentRequest xmlRequest = new XmlRequestAdapter("<key>value</key>");
        System.out.println(jsonRequest.getContent()); // 输出：{"key":"value"}
        System.out.println(xmlRequest.getContent());   // 输出：{"converted":"keyvaluekey"}
    }
}

价值体现：适配器隐藏了数据格式转换的复杂性，使核心逻辑无需关注输入来源。

四、适配器模式的最佳实践与注意事项

1. 明确适配目标：在实现前需清晰定义目标接口和被适配者的差异，避免过度设计。
2. 优先使用对象适配器：组合方式更灵活，支持动态替换被适配者。
3. 避免多层适配：过度使用适配器可能导致调用链复杂化，增加维护成本。
4. 结合其他模式：适配器可与工厂模式、策略模式结合使用，例如通过工厂创建不同类型的适配器。

五、总结与延伸思考

适配器模式通过中间层解决了接口不兼容的核心问题，其价值不仅体现在技术层面，更在于对系统演进的支持。在实际开发中，适配器模式常用于以下场景：

• 集成遗留系统与新架构。
• 统一第三方库的调用方式。
• 实现不同数据格式或协议的转换。

进一步思考：适配器模式与门面模式（Facade Pattern）有何区别？门面模式通过提供一个简化接口来隐藏子系统复杂性，而适配器模式专注于接口转换。两者可结合使用，例如通过门面模式对外暴露统一接口，内部使用适配器处理不同实现。

通过合理应用适配器模式，开发者能够构建更灵活、可扩展的系统，同时降低技术债务的积累。