每天认识一个设计模式-适配器模式：让不兼容的接口无缝协作

一、前言

在软件开发这片风云变幻的天地里，我们可能会遇到这些棘手的困境：

❓怎样才能让两个诞生于不同时期的系统，毫无阻碍地携手合作，宛如一体？

❓又能否在不触碰原有代码根基的情况下，巧妙实现接口兼容，确保现有系统的稳健运行？

这些绝非纸上谈兵的空想，而是每日都摆在开发者案头的现实挑战。​

此时，适配器模式作为潜在的破局之法，悄然登场。但它究竟是化解所有兼容难题的灵丹妙药，还是权宜之计，如同数字世界里的 “创可贴” 呢？

在这篇文章中，我们将深度解析适配器模式，探究其运行机制、适用场景与固有局限。期望通过此番探索，让大伙在面对整合异构系统、实现接口适配这类复杂难题时，能够游刃有余，做出精准且明智的抉择。

二、适配器模式的基础介绍

适配器模式（Adapter Pattern）充当两个不兼容接口之间的桥梁，属于结构型设计模式。它通过一个中间件（适配器）将一个类的接口转换成客户期望的另一个接口，使原本不能一起工作的类能够协同工作。

这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。旨在解决不同接口之间的兼容性问题。

在我们的日常生活中，读卡器是作为内存卡和笔记本之间的适配器。我们将内存卡插入读卡器，再将读卡器插入笔记本，这样就可以通过笔记本来读取内存卡。

因此根据这个逻辑我们在代码实现层面我们可以看到适配器模式也有着清晰的结构。我们可以简单看个例子：​

// 目标接口（现代USB-C） ​

interface UsbC { ​

void connect(); ​

} ​


// 被适配者（旧式USB-A） ​

class UsbA { ​

void plugIn() { ​

System.out.println("USB-A connected"); ​

} ​

} ​


// 适配器（转接头） ​

class UsbAdapter implements UsbC { ​

private UsbA usbA = new UsbA(); ​

​
@Override ​

public void connect() { ​

usbA.plugIn(); // 调用旧接口 ​

} ​

} ​


// 使用 ​

UsbC device = new UsbAdapter(); ​

device.connect(); // 输出：USB-A connected​

在这段代码中，UsbC接口代表现代的 USB-C 接口，它定义了connect方法，这是新设备期望的连接方式。UsbA类则模拟旧式的 USB-A 接口，其plugIn方法是旧设备的连接操作。UsbAdapter类作为适配器，实现了UsbC接口，并且在内部持有一个UsbA类的实例。

当调用UsbAdapter的connect方法时，实际上是调用了UsbA的plugIn方法。这样，通过UsbAdapter这个适配器，原本只能使用UsbA接口的设备，就能够以UsbC接口的方式被调用，实现了接口的转换和适配。就如同现实中的 Type-C 转 HDMI 转换器，将不同接口标准的设备连接起来，让它们能够协同工作。

因此这块对于适配器模式的结构就比较清晰了：

适配器模式包含以下几个主要角色：

• 目标接口（Target）：定义客户需要的接口。
• 适配者类（Adaptee）：定义一个已经存在的接口，这个接口需要适配。
• 适配器类（Adapter）：实现目标接口，并通过组合或继承的方式调用适配者类中的方法，从而实现目标接口。

 三、适配器模式在常见框架中的应用分析

为了更好了解这个模式的精髓，下面我们通过常见的开发框架来学习一下适配器模式的设计艺术：

1. Spring MVC 的 HandlerAdapter​

这个应该是所有Java开发这者都特别熟悉的框架了，包括平常面试都可能会让你介绍MVC的机制，那么这个HandlerAdapter应该体现最明确的适配器模式了。在 Spring MVC 框架里，请求处理流程涉及多个关键组件， HandlerAdapter 无疑发挥着举足轻重的适配器作用。

Spring MVC 的设计目标是能够灵活处理各种不同类型的请求处理器，如传统的 Servlet 以及基于注解的@Controller等。由于这些处理器接口和处理逻辑差异显著，需要一种机制来统一管理和调用，这正是 HandlerAdapter 诞生的背景。​

从源码角度深入剖析，HandlerAdapter是一个接口，其定义如下：

public interface HandlerAdapter {
    boolean supports(Object handler);
    ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler);
}

 supports方法用于判断当前适配器是否能够支持传入的handler对象，也就是判断该handler是否属于适配器能够处理的类型。而handle方法则承担着实际处理请求的重任，它接收HttpServletRequest、HttpServletResponse以及handler对象作为参数，执行handler的业务逻辑，并返回一个ModelAndView对象，该对象包含了处理结果的数据模型以及对应的视图信息。​

以HttpRequestHandlerAdapter为例，它是HandlerAdapter接口的一个具体实现类，其源码如下：

public class HttpRequestHandlerAdapter implements HandlerAdapter {
    @Override
    public boolean supports(Object handler) {
        return (handler instanceof HttpRequestHandler);
    }

    @Override
    public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        ((HttpRequestHandler) handler).handleRequest(request, response);
        return null;
    }
}

在supports方法中，通过判断handler是否为HttpRequestHandler类型来决定是否支持该处理器。如果支持，在handle方法中，会将handler强制转换为HttpRequestHandler类型，然后调用其handleRequest方法来处理请求。这里需要注意的是，由于HttpRequestHandler处理请求后并不返回ModelAndView对象（其主要专注于处理请求并直接向响应中写入数据），所以handle方法直接返回null。

这里我们可以大概了解适配器模式在MVC框架中的设计思想：

• 统一处理多种处理器：借助 HandlerAdapter，Spring MVC 成功将不同类型处理器的处理逻辑整合到统一的请求处理流程中。无论处理器是基于何种技术实现，只要为其编写对应的适配器，Spring MVC 就能无缝调用，极大提升了框架的灵活性与扩展性。​

• 新增处理器类型简便：当有新类型的处理器需要集成到 Spring MVC 框架时，开发者仅需创建一个实现HandlerAdapter接口的新适配器类。在这个类中，定义对新处理器类型的支持判断逻辑（在supports方法中）以及具体的处理逻辑（在handle方法中）。这种方式避免了对框架核心代码的大规模修改，有效降低了维护成本，显著提高了开发效率。

 除此以外还有JAVA中的I/O流也有适配器应用的身影。

2.Java I/O 的装饰者 + 适配器

Java I/O 体系结构设计精妙，其中适配器模式与装饰者模式相互交织，为开发者提供了丰富且强大的 I/O 操作能力。以将字节流适配为字符流这一常见操作为例，来看适配器模式的具体应用。​

在 Java I/O 中，InputStream是字节流的基础接口，用于处理以字节为单位的数据读取，而Reader是字符流的基础接口，专注于字符数据的读取。InputStreamReader类在此扮演了适配器的角色，其源码实现如下：

public class InputStreamReader extends Reader {
    private final StreamDecoder sd;

    public InputStreamReader(InputStream in) {
        this(in, Charset.forName("UTF-8"));
    }

    public InputStreamReader(InputStream in, String charsetName) {
        super(in);
        if (charsetName == null)
            throw new NullPointerException("charsetName");
        sd = StreamDecoder.forInputStreamReader(in, this, charsetName);
    }

    @Override
    public int read() throws IOException {
        return sd.read();
    }

    @Override
    public int read(char[] cbuf, int offset, int length) throws IOException {
        return sd.read(cbuf, offset, length);
    }

    // 其他方法省略
}

InputStreamReader类继承自Reader接口，并且内部持有一个StreamDecoder对象，而StreamDecoder又与传入的InputStream相关联。通过这种结构，InputStreamReader将字节流适配为字符流，使得开发者能够以字符为单位方便地读取字节流数据。​
实际应用场景中，当我们需要读取文本文件时，由于文本文件在磁盘上是以字节形式存储的，若直接使用InputStream操作，对于处理文本内容而言并不方便。而借助InputStreamReader将字节流转换为字符流后，我们可以按字符读取文件内容，并且能够指定字符编码格式（如 UTF - 8），从而确保文本的正确解析。例如：

try (InputStream inputStream = new FileInputStream("data.txt");
     Reader reader = new InputStreamReader(inputStream, "UTF-8")) {
    int data;
    while ((data = reader.read()) != -1) {
        System.out.print((char) data);
    }
} catch (IOException e) {
    e.printStackTrace();
}

这里FileInputStream创建了一个字节流用于读取文件，InputStreamReader将其适配为字符流，并且指定编码为 UTF - 8。之后通过reader.read()方法按字符读取文件内容并输出，充分体现了适配器模式在 Java I/O 体系中的实用价值。

3. SLF4J 日志门面

SLF4J（Simple Logging Facade for Java）作为一款广泛使用的日志门面，为 Java 开发者提供了统一的日志接口。这一设计使得开发者在应用开发过程中，无需紧密依赖特定的日志实现框架（如 Log4j、Logback 等），从而能够在不修改大量应用代码的前提下，灵活切换底层日志框架。在将 Log4j 适配到 SLF4J 接口的过程中，适配器模式发挥了关键作用。

从依赖配置角度看，若要将 Log4j 适配到 SLF4J 接口，需要在项目的pom.xml文件中引入如下依赖：​

<dependency>​

<groupId>org.slf4j</groupId>​

<artifactId>slf4j-log4j12</artifactId>​

<version>￥{slfj.version}</version>​

</dependency>​

这个slf4j-log4j12依赖包中包含了将 Log4j 适配到 SLF4J 接口的核心实现。深入到源码层面，Log4jLoggerAdapter类是实现适配的关键。虽然不同版本的 SLF4J 和 Log4j 对应的Log4jLoggerAdapter源码可能略有差异，但总体结构相似，大致如下：

public class Log4jLoggerAdapter implements org.slf4j.Logger {
    private final org.apache.log4j.Logger log4jLogger;

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

    @Override
    public void trace(String msg) {
        if (log4jLogger.isTraceEnabled()) {
            log4jLogger.trace(msg);
        }
    }

    @Override
    public void debug(String msg) {
        if (log4jLogger.isDebugEnabled()) {
            log4jLogger.debug(msg);
        }
    }

    // 其他日志级别方法类似
}

Log4jLoggerAdapter类实现了 SLF4J 的Logger接口，并且在内部持有一个org.apache.log4j.Logger对象。在实现 SLF4J 的日志方法（如trace、debug等）时，会先判断对应的 Log4j 日志级别是否启用，如果启用则调用log4jLogger的相应方法来执行实际的日志记录操作。​

这种适配机制赋予了开发者极大的灵活性。例如，当项目最初选择 Log4j 作为日志框架，随着项目演进，由于某些原因需要切换到 Logback 时，开发者只需修改项目的依赖配置，引入slf4j-logback相关依赖，而无需对应用代码中大量的日志调用语句进行修改，极大地提高了项目的可维护性和可扩展性，充分体现了适配器模式在日志框架适配场景中的重要价值。

四、自定义适配器模式

在实际的开发中，软件系统往往需要不断适应新的业务需求和变化。以媒体播放器开发为例，假设初始版本的媒体播放器仅支持播放 MP4 格式的视频文件。随着业务拓展，客户要求播放器能够支持更多常见视频格式，如 AVI、WMV 等。若直接在原有代码基础上进行大规模修改，不仅可能引入新的 bug，还会使代码结构变得复杂难以维护。此时，自定义适配器模式便能有效解决这一问题。​

1. 定义目标接口​

先定义一个目标接口，该接口用于规范媒体播放器播放多种格式视频的统一行为。

package com.example.mediaplayer.service;

// 定义多格式播放器服务接口，规范播放不同格式视频的行为
public interface MultiFormatPlayerService {
    // 接收视频格式和文件路径作为参数，执行播放操作
    void play(String videoFormat, String videoFile);
}

play方法接收视频格式和视频文件路径作为参数，用于执行播放操作。​

2. 现有播放器类（适配者）​

假设现有的播放器类MP4Player只能播放 MP4 格式视频，那么我们就可以将其视为一个适配者：

package com.example.mediaplayer.service;

// MP4播放器服务类，实现播放MP4格式视频的功能
public class MP4PlayerService {
    // 播放MP4文件的方法
    public void playMP4(String mp4File) {
        // 模拟业务校验，检查文件是否存在
        if (!new java.io.File(mp4File).exists()) {
            throw new IllegalArgumentException("MP4 file does not exist: " + mp4File);
        }
        System.out.println("Playing MP4 file: " + mp4File);
    }
}

虽然这个类提供了播放 MP4 文件的功能，但不符合新的多格式播放的目标接口。​

3. 自定义适配器类​

接下来创建自定义适配器类，使其实现MultiFormatPlayerService接口，并在内部使用MP4PlayerService处理 MP4 格式，同时添加对新格式的支持逻辑。除了 AVI 格式，再增加对 WMV 格式的支持，假设我们有相应的第三方库AVIPlayerLibrary和WMVPlayerLibrary来处理 AVI 和 WMV 文件，自定义适配器类VideoPlayerAdapterService可以这样实现：

package com.example.mediaplayer.service;

import thirdPartyAVI.AVIPlayerLibrary;
import thirdPartyWMV.WMVPlayerLibrary;

// 视频播放器适配器服务类，实现多格式播放器服务接口
public class VideoPlayerAdapterService implements MultiFormatPlayerService {
    // 持有MP4播放器服务对象
    private MP4PlayerService mp4Player;
    // 持有AVI播放器库对象
    private AVIPlayerLibrary aviPlayer;
    // 持有WMV播放器库对象
    private WMVPlayerLibrary wmvPlayer;

    // 构造函数，初始化各个播放器对象
    public VideoPlayerAdapterService() {
        mp4Player = new MP4PlayerService();
        aviPlayer = new AVIPlayerLibrary();
        wmvPlayer = new WMVPlayerLibrary();
    }

    // 实现多格式播放器服务接口的play方法
    @Override
    public void play(String videoFormat, String videoFile) {
        // 如果是MP4格式，调用MP4播放器服务的playMP4方法
        if ("mp4".equalsIgnoreCase(videoFormat)) {
            mp4Player.playMP4(videoFile);
        } 
        // 如果是AVI格式，进行分辨率校验后调用AVI播放器库的playAVI方法
        else if ("avi".equalsIgnoreCase(videoFormat)) {
            if (!aviPlayer.isResolutionSuitable(videoFile)) {
                throw new IllegalArgumentException("AVI file resolution not suitable: " + videoFile);
            }
            aviPlayer.playAVI(videoFile);
        } 
        // 如果是WMV格式，进行版权校验后调用WMV播放器库的playWMV方法
        else if ("wmv".equalsIgnoreCase(videoFormat)) {
            if (!wmvPlayer.isCopyrightValid(videoFile)) {
                throw new IllegalArgumentException("WMV file copyright issue: " + videoFile);
            }
            wmvPlayer.playWMV(videoFile);
        } 
        // 对于不支持的格式，抛出异常
        else {
            throw new IllegalArgumentException("Format not supported yet: " + videoFormat);
        }
    }
}

在play方法中，依据传入的视频格式，对不同格式分别进行业务处理。通过这种适配方式，实现了将多种不同格式视频的播放逻辑整合到一个统一的接口下，满足了业务对多格式播放的需求。

4. 使用自定义适配器​

package com.example.mediaplayer.controller;

import com.example.mediaplayer.service.MultiFormatPlayerService;
import com.example.mediaplayer.service.VideoPlayerAdapterService;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

// 媒体播放器控制器类，处理外部请求
@RestController
public class MediaPlayerController {
    // 持有多格式播放器服务对象
    private final MultiFormatPlayerService player;

    // 构造函数，初始化多格式播放器服务对象为视频播放器适配器服务对象
    public MediaPlayerController() {
        player = new VideoPlayerAdapterService();
    }

    // 处理播放视频请求的方法，接收视频格式和文件路径参数
    @GetMapping("/play")
    public ResponseEntity<String> playVideo(@RequestParam String format, @RequestParam String file) {
        try {
            // 调用多格式播放器服务的play方法进行播放
            player.play(format, file);
            // 播放成功，返回成功响应
            return new ResponseEntity<>("Playing video: " + file + " in format " + format, HttpStatus.OK);
        } catch (IllegalArgumentException e) {
            // 捕获非法参数异常，返回错误响应
            return new ResponseEntity<>(e.getMessage(), HttpStatus.BAD_REQUEST);
        }
    }
}

通过这种分层设计，在不改变原有MP4PlayerService类的基础上，成功扩展了媒体播放器的功能，使其支持多种视频格式的播放。

五、总结：适配器——是桥梁也是双刃剑

适配器的好，谁用谁知道：
就像给你的旧手机配了个Type-C转接头，适配器模式让那些「老古董」代码也能跟上新时代的步伐。不用改祖传代码、不用重新造轮子，加个「中间商」就能让水火不容的接口称兄道弟——这波操作，真香！

但别急着夸，缺点也得唠：

⛔转接头也有重量：每多一层适配，就多一丝性能损耗（虽然通常微乎其微）

⛔套娃警告：见过为了适配而适配，最后搞出「适配器套适配器」的俄罗斯套娃吗？那代码简直比洋葱还催泪

⛔治标不治本：如果两个系统压根不该对话，强行适配就像给骆驼和企鹅牵红线——早晚得出事

适合搬出适配器的三大场景：
✅ 救火队长：紧急对接第三方库，来不及改对方代码时
✅ 和平使者：整合不同团队开发的子系统，接口标准不统一时
✅ 时光机：逐步迁移遗留系统，新旧版本共存过渡期

理性使用设计模式の哲学：
别把适配器当创可贴，哪里不兼容贴哪里。就像你不会因为螺丝刀好用就拿来切菜——先问三个问题：

1. 这真的是接口不兼容的问题吗？

2. 长期维护成本会不会更高？

3. 有没有更优雅的解决方案？（比如统一接口规范）

记住，设计模式不是银弹，而是工具箱里的螺丝刀。用对了省时省力，用错了就是给自己挖坑。下次遇到接口冲突时，不妨先喝口水冷静想想：这个场景，真的需要请出适配器大神吗？

---

互动话题：
你在工作中用过最「骚」的适配器操作是什么？评论区等你来秀！ 🚀

---

往期相关文章

每天认识一个设计模式 - 单例模式：独一无二的对象管家

每天认识一个设计模式 - 代理模式：程序世界的 “代言人”

每天认识一个设计模式 - 工厂模式：代码世界的“流水线“是怎样炼成的？

每日认识一个设计模式-建造者模式：复杂对象的“装配式革命“

每天认识一个设计模式-原型模式：对象克隆的“影分身之术“