适配器是什么意思

题图来自Unsplash，基于CC0协议

导读

适配器就是一种起到连接和转换作用的东西，虽然它在不同的场景中含义不同，但核心功能都是为了让原本不兼容的两个部分能够正常工作。这一点可能听起来有些抽象，但其实我们生活中处处都在和适配器打交道。

首先，最常见的可能就是电源适配器了。如果你有一台笔记本电脑、一个手机充电器、或者一个路由器，那么你都会用到电源适配器。它的作用主要是为了将我们日常生活中的交流电（比如家庭用电）转换成电子设备可以直接使用的直流电，并且根据设备的接口要求，把电流的形状（比如电压、电流、插头形状）也调整好。举个例子，我们家中常见的墙壁插座通常是两脚或三脚的，而笔记本电脑的电源接口可能是一个圆形三脚插头，这个时候就需要一个适配器来改变接口的形状和转换电压等级。你知道适配器这个词的由来吗？英文中的 adapter 本来是指“使适应某种用途的装置”，是拉丁语词根的演变，本身就带有一种让人适应不同环境的意思。

说到连接作用，这里又涉及到另一个含义：软件设计中的适配器模式。简单来说，这是一种软件结构，用来连接两个不同接口的对象或者系统，让它们能够协同工作。比如，你可能需要和不同版本的数据库打交道，但代码都希望用统一的方式来操作数据库。这时就可以使用适配器模式来“包装”这些旧系统或不同接口的数据库，让它们符合新代码的标准，就像在两者之间架起一座桥，让新老系统能“互认互通”。

听起来很像，但电源适配器和软件适配器却有着本质区别。电源适配器偏向硬件，它处理的是物理上的电流转换、电压调整和接口匹配，而且通常一次性加工制造完成，不可更改；而软件适配器偏向设计逻辑，是代码的一部分，它通过编写适配器类或函数，实现对接口中不兼容的部分，而且适配器模式可以根据项目需求灵活设计和修改。

适配器模式在软件开发中用到的场景非常多，比如新旧系统集成、框架扩展、第三方库的接口适配等。比如在游戏开发中，游戏角色的属性可能存储在不同格式的数据文件里，但游戏角色类需要一组固定的属性，这时就可以写一个适配器，把不同格式的数据统统“翻译”成角色能听懂的语言。

有趣的是，这两个“名字”都叫适配器，但它们一个负责电力转换，一个负责数据接口转换，所以也可以理解为一座“硬件桥”和一座“软件桥”。无论在哪个场景下，适配器真正体现的，都是一种衔接、转化、提升兼容性的底层思维。说得更简单一点，它就是那种让原来插不进去的东西，最终也能插得顺畅的工具。

再来说说适配器模式，它的应用场景也会逐步向复杂世界的环节扩展。比如你可能曾经遇到过代码中调用了某个第三方库，但这个库的方法和你的期望不一致，甚至抛出的异常格式也不兼容，这时候不用大改代码或者重写库，你只需要编写一个适配器包装层，把第三方库的输出按照你自己的设想重新组织，你和第三方之间的“语言差”就迎刃而解了。

这种模块化的结构给了软件设计灵活的扩展力，也符合软件工程的一句话：小的改动专注于局部，大的改动通过适配器来隔离。你不会直接去更改系统的内核或基础模块，而是把这个棘手的变化封装在一个适配器里。

当然，适配器最重要的作用还是松耦合——你只使用适配器，不会直接依赖原始接口。这对于大型系统维护、团队协作真的很有帮助。比如你想引入一个新的支付接口，但现有的订单处理系统只接受一个特定的接口，直接修改订单处理系统就会引起连锁反应，这个时候你就可以引入一个支付接口适配器，让新旧系统各自走在自己的轨道上，还能灵活切换。

所以，当你打开一个复杂系统的时候，适配器是那些不易被注意，但无处不在的关键部分，它们是系统之间桥梁与耦合的隐形元老。如果你发现在某个地方需要连接两个不同体系的东西，别急着大改，先想想适配器。它可能成为你优雅解决问题的最佳选择。

许多人听到“适配器”这个词会本能地想到硬件，比如手机充电器或数据线接口，但实际上在软件和系统层面，也有很多与适配器模式相关的应用。适配器模式通常用来解决接口不匹配的问题，让原本不能直接合作的类或者系统能够协同工作。例如，假设你正在开发一个图形应用框架，它要求所有图形渲染都通过一个标准接口实现（比如 draw() 方法）。但现在你有两个原本不兼容的第三方库，一个擅长绘制 2D 图形，另一个擅长 3D 图形，但它们的接口设计完全不同。这时，适配器模式就可以派上用场：

你可以创建两个适配器类，分别是 LegacyRendererAdapter 和 ModernRendererAdapter，它们都实现了框架要求的标准接口。然后，在适配器类内部，调用你原始库的具体方法。比如：

class StandardRenderer:
    def draw(self, obj):
        pass

# 假设这是框架要求的标准接口

# 适配器模式实现：第1种
class LegacyRendererAdapter(StandardRenderer):
    def __init__(self, legacy_renderer):
        self.legacy_renderer = legacy_renderer

    def draw(self, obj):
        # 将框架的格式转换成旧库的格式
        old_format = self.convert_to_legacy_format(obj)
        self.legacy_renderer.render(old_format)

# 类似地，适配2号库

class ModernRendererAdapter(StandardRenderer):
    def __init__(self, modern_renderer):
        self.modern_renderer = modern_renderer

    def draw(self, obj):
        # 将框架的格式转换成新库的格式
        converted_obj = self.convert_to_modern_format(obj)
        self.modern_renderer.display(converted_obj)

# 这样，原框架就可以统一调用这两个适配器，因为它总是在调用 StandardRenderer 接口。

这样，框架代码不需要修改，你却可以随意接入更多的图形库，因为不同的库被适配到同一个标准接口上。这也是适配器模式解耦的魅力所在。

从定义上来说，适配器模式就像一个翻译官。在软件设计领域，你经常需要和不同结构、不兼容的对象协作，即使对象的功能相同，但它们的内部方法和数据格式却可能千差万别。这时候，适配器模式就承包了这个转换工作，让调用者（比如你的主程序或者模块）感觉不到背后复杂的变化，从而保持整个代码系统的简洁和可维护性。

我们知道，英文单词 adapter 是“适配器”的意思，也和这个词的核心功能有关。在技术词汇的翻译中，很多概念都是直接借用英文单词，但在汉语中并没有一种类似的统一发音或者理解，所以 adapter 这个音译词，在我们使用时，反而就多了一层直观的理解——它就是用来“使…适应”的工具。