8、（结构型设计模式）Java 适配器模式深度学习指南

以下是为你精心撰写的 《Java 适配器模式深度学习指南》，专为 Java 后端开发者打造，内容涵盖：定义、作用、与桥接模式的深度对比、真实业务场景、实现方式（类适配器、对象适配器）、Spring 集成、避坑指南、最佳实践、面试高频题，所有示例均含中文注释，可直接用于项目重构、第三方 SDK 接入、遗留系统兼容、微服务网关等实战场景。

---

📘 Java 适配器模式深度学习指南

—— 从“接口不兼容”到“无缝衔接”的架构桥梁

作者：Java 后端架构实战导师
适用对象：Java 后端开发者（Spring Boot / 微服务 / 第三方 SDK / 遗留系统 / API 网关）
目标：彻底掌握“让不兼容的接口协同工作”的核心设计模式，告别“改旧代码、写胶水代码”的痛苦
核心原则：“我不是改你，我是帮你穿上新衣服”

---

✅ 一、什么是适配器模式？

📌 定义：

适配器模式（Adapter Pattern） 是一种结构型设计模式，它将一个类的接口转换成客户端期望的另一个接口，使原本因接口不兼容而无法一起工作的类可以协同工作。

🔍 核心思想：

• 你有一个老系统（或第三方库），它的接口是 OldInterface
• 你的新系统需要调用 NewInterface
• 你不能修改老系统（因为是第三方、遗留代码、不可控）
• 你写一个适配器类，实现 NewInterface，内部调用 OldInterface
• 客户端只看到 NewInterface，完全感知不到老系统的存在

💡 一句话记忆：
“你用的是 USB-C，我只有 USB-A，我给你一个转换头，你照样能充电。”

🆚 适配器模式 vs 桥接模式（易混淆点）

维度	适配器模式	桥接模式
目的	兼容已有接口（解决不兼容）	解耦抽象与实现（让两者独立变化）
出发点	“我需要调用旧系统，但接口不匹配”	“我想让抽象和实现都能自由扩展”
结构	适配器包装一个现有类	抽象类持有一个实现接口
是否改变原系统	❌ 不修改原系统，只包装	✅ 原系统需拆分为抽象和实现两部分
典型场景	第三方 SDK、遗留系统兼容	JDBC 驱动 + 连接池、UI 主题 + 控件
类比	电源转换插头	可插拔的灯泡 + 灯座

✅ 关键区别：

• 适配器：接口不兼容 → 我来适配
• 桥接：抽象和实现都可能变 → 我来解耦

---

✅ 二、适配器模式有什么作用？（Why Use Adapter Pattern?）

作用	说明
✅ 兼容第三方库	无缝接入微信、支付宝、阿里云、腾讯云等 SDK，无需改业务代码
✅ 兼容遗留系统	老系统用 XML 接口，新系统用 JSON，写适配器过渡
✅ 统一接口风格	多个外部服务接口不一致，统一为内部标准接口
✅ 避免修改源码	对第三方库、开源组件、遗留代码，不能改源码时的唯一选择
✅ 支持渐进式重构	新旧系统并行运行，逐步迁移，降低风险
✅ 提高可测试性	可 Mock 适配器，测试新系统无需依赖真实第三方
✅ 降低耦合度	客户端只依赖统一接口，不依赖具体实现

💡 经典名言：
“When you have an existing class with an incompatible interface, use the Adapter pattern to make it usable.”
——《Design Patterns: Elements of Reusable Object-Oriented Software》

---

✅ 三、适配器模式的典型使用场景（Java 后端真实案例）

场景	说明	是否推荐使用适配器模式
✅ 接入第三方支付 SDK	微信支付接口 vs 支付宝接口 vs 银联接口，统一为 PaymentService	✅ 强烈推荐
✅ 短信服务商切换	阿里云短信、腾讯云短信、自建短信平台，统一为 SmsSender	✅ 推荐
✅ 日志系统迁移	旧系统用 Log4j，新系统用 SLF4J，写适配器兼容	✅ 推荐
✅ 数据库驱动兼容	旧代码用 java.sql.Connection，新框架用 javax.sql.DataSource	✅ 推荐
✅ API 网关请求转换	外部请求是 REST，内部服务是 gRPC，写适配器转换	✅ 推荐
✅ 消息队列适配	Kafka、RabbitMQ、RocketMQ 统一为 MessageBroker 接口	✅ 推荐
✅ 缓存系统切换	Redis、Memcached、Caffeine 统一为 CacheProvider	✅ 推荐
✅ 文件格式转换	读取 .xls 文件，但内部用 CSVParser 接口	✅ 推荐
❌ 简单工具类封装	StringUtils 封装 String 方法	❌ 用静态方法即可
❌ 接口设计不规范	自己写的接口不一致，应统一设计	❌ 应重构，而非适配

✅ 判断标准：
“我必须调用一个外部系统，但它的接口和我系统要求的不一致，且我不能改它？”
→ 是 → 用适配器模式！

---

✅ 四、适配器模式的两种实现方式详解（含中文注释）

我们从对象适配器（推荐）到类适配器（少用），逐步深入。

---

🔹 1. 对象适配器（Object Adapter）—— 最常用、最推荐

原理：通过组合（Has-A）方式，适配器持有一个被适配对象的引用。

/**
 * 【1】我们系统期望的统一支付接口（新接口）
 */
interface PaymentService {
    boolean pay(double amount); // 支付金额，返回成功与否
    String getPaymentMethod(); // 获取支付方式名称
}

/**
 * 【2】微信支付 SDK（第三方旧接口，我们不能修改）
 */
class WeChatPaySDK {
    // 微信 SDK 的原始方法（与我们期望的接口不一致）
    public void wechatPay(double amount) {
        System.out.println("📱 微信支付 SDK：支付 " + amount + " 元");
    }

    public String getWechatName() {
        return "微信支付";
    }
}

/**
 * 【3】支付宝 SDK（第三方旧接口，我们不能修改）
 */
class AlipaySDK {
    // 支付宝 SDK 的原始方法
    public void alipay(double amount) {
        System.out.println("💳 支付宝 SDK：支付 " + amount + " 元");
    }

    public String getAlipayName() {
        return "支付宝";
    }
}

/**
 * 【4】微信支付适配器：实现我们的 PaymentService 接口，内部调用 WeChatPaySDK
 */
class WeChatPayAdapter implements PaymentService {
    private WeChatPaySDK wechatSDK; // 组合：持有被适配对象

    public WeChatPayAdapter(WeChatPaySDK wechatSDK) {
        this.wechatSDK = wechatSDK;
    }

    @Override
    public boolean pay(double amount) {
        // 调用第三方 SDK 的方法，适配为我们的接口
        wechatSDK.wechatPay(amount);
        return true; // 假设总是成功
    }

    @Override
    public String getPaymentMethod() {
        // 调用第三方方法，转换为我们的接口返回
        return wechatSDK.getWechatName();
    }
}

/**
 * 【5】支付宝支付适配器
 */
class AlipayAdapter implements PaymentService {
    private AlipaySDK alipaySDK;

    public AlipayAdapter(AlipaySDK alipaySDK) {
        this.alipaySDK = alipaySDK;
    }

    @Override
    public boolean pay(double amount) {
        alipaySDK.alipay(amount);
        return true;
    }

    @Override
    public String getPaymentMethod() {
        return alipaySDK.getAlipayName();
    }
}

/**
 * 【6】客户端：只依赖统一接口 PaymentService，完全不知道底层是微信还是支付宝
 */
public class ObjectAdapterDemo {
    public static void main(String[] args) {
        // 创建第三方 SDK 实例
        WeChatPaySDK wechatSDK = new WeChatPaySDK();
        AlipaySDK alipaySDK = new AlipaySDK();

        // 创建适配器，将旧接口转换为新接口
        PaymentService wechatService = new WeChatPayAdapter(wechatSDK);
        PaymentService alipayService = new AlipayAdapter(alipaySDK);

        // ✅ 客户端只使用统一接口，完全解耦
        System.out.println("=== 微信支付 ===");
        wechatService.pay(199.9);
        System.out.println("支付方式：" + wechatService.getPaymentMethod());

        System.out.println("\n=== 支付宝支付 ===");
        alipayService.pay(299.9);
        System.out.println("支付方式：" + alipayService.getPaymentMethod());

        // 输出：
        // === 微信支付 ===
        // 📱 微信支付 SDK：支付 199.9 元
        // 支付方式：微信支付
        //
        // === 支付宝支付 ===
        // 💳 支付宝 SDK：支付 299.9 元
        // 支付方式：支付宝
    }
}

✅ 优点：

• 符合组合优于继承原则
• 支持动态切换：可运行时注入不同适配器
• 灵活：一个适配器可包装多个对象
• 易于测试：可 Mock WeChatPaySDK 进行单元测试
• 推荐用于生产环境

⚠️ 缺点：

• 每个适配器都要写一个包装类（代码量略多）

---

🔹 2. 类适配器（Class Adapter）—— 继承方式（不推荐）

原理：通过继承（Is-A）方式，适配器继承被适配类，同时实现目标接口。

/**
 * 【1】目标接口（同上）
 */
interface PaymentService {
    boolean pay(double amount);
    String getPaymentMethod();
}

/**
 * 【2】微信 SDK（同上）
 */
class WeChatPaySDK {
    public void wechatPay(double amount) {
        System.out.println("📱 微信支付 SDK：支付 " + amount + " 元");
    }

    public String getWechatName() {
        return "微信支付";
    }
}

/**
 * 【3】类适配器：继承 WeChatPaySDK，实现 PaymentService 接口
 * 注意：Java 不支持多重继承，只能继承一个类
 */
class WeChatPayClassAdapter extends WeChatPaySDK implements PaymentService {

    @Override
    public boolean pay(double amount) {
        // 调用父类方法
        wechatPay(amount);
        return true;
    }

    @Override
    public String getPaymentMethod() {
        // 调用父类方法
        return getWechatName();
    }
}

/**
 * 【4】客户端使用（与对象适配器相同）
 */
public class ClassAdapterDemo {
    public static void main(String[] args) {
        PaymentService adapter = new WeChatPayClassAdapter(); // 直接创建
        adapter.pay(150.0);
        System.out.println("支付方式：" + adapter.getPaymentMethod());

        // 输出：
        // 📱 微信支付 SDK：支付 150.0 元
        // 支付方式：微信支付
    }
}

✅ 优点：

• 代码更简洁（一个类搞定）
• 调用父类方法直接

❌ 缺点：

• 违反组合优于继承原则
• 只能适配一个类（Java 单继承限制）
• 耦合度高：适配器与被适配类强绑定
• 难以测试：无法 Mock 父类行为
• 不推荐在生产中使用

✅ 结论：优先使用对象适配器，除非你有特殊理由必须用继承

---

🔹 3. 适配器模式 + Spring（企业级实战）

在 Spring 中，适配器模式无处不在！我们用 @Bean + 接口统一管理。

/**
 * 【1】统一支付接口（我们的标准）
 */
public interface PaymentService {
    boolean pay(double amount);
    String getPaymentMethod();
}

/**
 * 【2】微信 SDK（第三方，我们不能改）
 */
class WeChatPaySDK {
    public void wechatPay(double amount) {
        System.out.println("📱 微信支付 SDK：支付 " + amount + " 元");
    }

    public String getWechatName() {
        return "微信支付";
    }
}

/**
 * 【3】支付宝 SDK（第三方，我们不能改）
 */
class AlipaySDK {
    public void alipay(double amount) {
        System.out.println("💳 支付宝 SDK：支付 " + amount + " 元");
    }

    public String getAlipayName() {
        return "支付宝";
    }
}

/**
 * 【4】微信支付适配器（Spring Bean）
 */
@Component
@Primary // 默认实现
@Qualifier("wechat")
public class WeChatPayAdapter implements PaymentService {

    private final WeChatPaySDK wechatSDK;

    public WeChatPayAdapter() {
        this.wechatSDK = new WeChatPaySDK(); // 或者通过 @Autowired 注入
    }

    @Override
    public boolean pay(double amount) {
        wechatSDK.wechatPay(amount);
        return true;
    }

    @Override
    public String getPaymentMethod() {
        return wechatSDK.getWechatName();
    }
}

/**
 * 【5】支付宝支付适配器（Spring Bean）
 */
@Component
@Qualifier("alipay")
public class AlipayAdapter implements PaymentService {

    private final AlipaySDK alipaySDK;

    public AlipayAdapter() {
        this.alipaySDK = new AlipaySDK();
    }

    @Override
    public boolean pay(double amount) {
        alipaySDK.alipay(amount);
        return true;
    }

    @Override
    public String getPaymentMethod() {
        return alipaySDK.getAlipayName();
    }
}

/**
 * 【6】支付服务（业务层）
 */
@Service
public class OrderService {

    @Autowired
    @Qualifier("wechat") // 根据配置动态注入
    private PaymentService paymentService; // ✅ 客户端只依赖统一接口

    public void processPayment(double amount) {
        System.out.println("🛒 开始支付 " + amount + " 元");
        boolean success = paymentService.pay(amount);
        if (success) {
            System.out.println("✅ 支付成功，方式：" + paymentService.getPaymentMethod());
        }
    }
}

/**
 * 【7】配置类：根据配置文件动态选择支付方式
 */
@Configuration
public class PaymentConfig {

    @Value("${payment.type:wechat}") // 默认用微信
    private String paymentType;

    @Bean
    @Primary
    public PaymentService paymentService() {
        return switch (paymentType.toLowerCase()) {
            case "alipay" -> new AlipayAdapter();
            case "wechat" -> new WeChatPayAdapter();
            default -> throw new IllegalArgumentException("不支持的支付类型：" + paymentType);
        };
    }
}

/**
 * 【8】配置文件：application.yml
 */
/*
payment:
  type: alipay  # 切换为 wechat 或 alipay，无需改代码！
*/

/**
 * 【9】启动类测试
 */
@SpringBootApplication
public class SpringAdapterDemo {
    public static void main(String[] args) {
        ApplicationContext context = SpringApplication.run(SpringAdapterDemo.class, args);
        OrderService service = context.getBean(OrderService.class);
        service.processPayment(99.9);
        // 输出：
        // 🛒 开始支付 99.9 元
        // 💳 支付宝 SDK：支付 99.9 元
        // ✅ 支付成功，方式：支付宝
    }
}

✅ 优点：

• 零耦合：业务层完全不知道底层是微信还是支付宝
• 配置驱动：通过 application.yml 动态切换支付方式
• 可测试：可 Mock PaymentService 进行单元测试
• 真正企业级：Spring Boot 中的 RestTemplate、MessageConverter、DataSource 都是适配器模式！

---

🔹 4. 适配器模式 + 日志系统（真实历史案例）

Java 日志系统迁移：从 Log4j 到 SLF4J

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

/**
 * 【1】我们系统期望的日志接口（标准）
 */
interface LoggerService {
    void info(String message);
    void error(String message);
}

/**
 * 【2】旧系统：Log4j 日志（第三方，我们不能改）
 */
import org.apache.log4j.Logger as Log4jLogger;

class Log4jWrapper implements LoggerService {
    private org.apache.log4j.Logger log4jLogger;

    public Log4jWrapper(String name) {
        this.log4jLogger = org.apache.log4j.Logger.getLogger(name);
    }

    @Override
    public void info(String message) {
        log4jLogger.info(message); // 适配
    }

    @Override
    public void error(String message) {
        log4jLogger.error(message); // 适配
    }
}

/**
 * 【3】新系统：SLF4J（标准）
 */
class Slf4jWrapper implements LoggerService {
    private org.slf4j.Logger slf4jLogger;

    public Slf4jWrapper(String name) {
        this.slf4jLogger = LoggerFactory.getLogger(name);
    }

    @Override
    public void info(String message) {
        slf4jLogger.info(message); // 适配
    }

    @Override
    public void error(String message) {
        slf4jLogger.error(message); // 适配
    }
}

/**
 * 【4】客户端统一使用 LoggerService
 */
public class LoggingDemo {
    public static void main(String[] args) {
        LoggerService logger = new Slf4jWrapper("OrderService"); // 切换为 Log4jWrapper 也行

        logger.info("用户登录成功");
        logger.error("支付失败，余额不足");
    }
}

✅ 现实世界：SLF4J 本身就是一个门面模式 + 适配器模式的结合体！
它提供统一接口，内部适配 Log4j、Logback、JUL 等实现。

---

✅ 五、适配器模式的避坑指南（Java 后端高频踩坑）

问题	原因	解决方案
❌ 用适配器模式解决“自己设计的接口不一致”	应该统一设计，而非适配	✅ 重构接口，不要用适配器掩盖设计缺陷
❌ 适配器中包含业务逻辑	适配器只做“转换”，不做“处理”	✅ 业务逻辑放在服务层，适配器只转发
❌ 忘记封装第三方异常	客户端收到原始异常，无法统一处理	✅ 在适配器中捕获异常，转换为统一业务异常
❌ 适配器类命名混乱	WeChatPayAdapterImpl 太长	✅ 命名：WeChatPayAdapter 即可，清晰即可
❌ 用类适配器导致继承链过深	多层继承，难以维护	✅ 优先用对象适配器
❌ 没有单元测试	依赖真实第三方，测试慢	✅ 用 Mockito Mock 适配器中的 SDK

---

✅ 六、适配器模式 vs 桥接模式 对比总结表

维度	适配器模式	桥接模式
目的	解决接口不兼容	解耦抽象与实现
关系	包装（Wrapper）	组合（Has-A）
改变对象	不改原对象	拆分原对象
扩展方向	扩展适配器	扩展抽象和实现
典型场景	第三方 SDK、遗留系统	JDBC、UI 主题、消息队列
类比	电源转换插头	可插拔灯泡 + 灯座

✅ 一句话区分：

• 适配器：“你和我接口不一样，我来帮你穿新鞋”
• 桥接：“你和我本来是一体的，现在我们分开，各自进化”

---

✅ 七、学习建议与进阶路径

阶段	建议
📚 第一周	在你的项目中，为微信/支付宝 SDK 写一个适配器，统一为 PaymentService
📚 第二周	用 Spring @Bean + @Qualifier 实现支付方式动态切换
📚 第三周	为你的项目中一个遗留系统（如 XML 接口）写一个适配器，转换为 JSON
📚 第四周	阅读 Spring 源码：RestTemplate 如何适配不同 HttpMessageConverter？
📚 面试准备	准备回答：

“你项目中哪里用了适配器模式？”
“对象适配器和类适配器区别？”
“适配器模式和桥接模式区别？”
“Spring 中的 @Bean 是适配器吗？” |

---

✅ 八、适配器模式面试高频题（附答案）

Q1：适配器模式解决了什么问题？

A：解决两个不兼容接口之间的协作问题，让它们无需修改源码就能协同工作。

Q2：对象适配器和类适配器的区别？

A：

• 对象适配器：组合（Has-A），通过持有被适配对象实现
• 类适配器：继承（Is-A），通过继承被适配类实现
  → 推荐使用对象适配器，更灵活、安全。

Q3：适配器模式和桥接模式的区别？

A：

• 适配器：接口不兼容 → 我来适配
• 桥接：抽象和实现都可能变 → 我来解耦
  → 一个解决“兼容性”，一个解决“扩展性”

Q4：Spring 中哪些地方用了适配器模式？

A：

• RestTemplate → 适配 HttpMessageConverter
• MessageConverter → 适配 JSON、XML、Protobuf
• HandlerAdapter → 适配不同 Controller 类型
• DataSource → 适配不同数据库驱动
  → Spring 的核心思想就是“适配一切”！

Q5：什么时候不该用适配器模式？

A：

• 你可以修改源码，应直接统一接口
• 你只是想封装工具类，应使用静态方法
• 你想让抽象和实现独立演化，应使用桥接模式

---

✅ 九、总结：适配器模式选型决策树

graph TD
    A[是否需要接入第三方或遗留系统？] --> B{接口不兼容？}
    B -->|是| C[使用对象适配器 + 组合]
    B -->|否| D[不需要适配器]
    C --> E[是否在 Spring 项目中？]
    E -->|是| F[用 @Bean + @Qualifier + 配置文件动态注入]
    E -->|否| G[手动创建适配器实例]

✅ 最终推荐：

• Spring 项目 → ✅ 对象适配器 + @Bean + 配置驱动（最优雅）
• 非 Spring 项目 → ✅ 对象适配器（最安全）
• 绝对不要：类适配器、在适配器中写业务逻辑、用适配器掩盖设计缺陷

---

✅ 十、结语：真正的高手，不改别人，只做转换

你不是在学“适配器模式”，你是在学“如何在不破坏世界的情况下，让世界为你所用”。

✅ 当你看到 @Bean PaymentService 由 WeChatPayAdapter 实现，而业务层完全不知道时，你已经掌握了企业级架构的精髓。
✅ 当你用 application.yml 切换支付方式，而不用重启服务时，你已经是架构师了。

不要为了“用模式”而用模式，
要为了“系统可集成、可演进、可维护”而选择它。

---