结构型设计模式之适配器模式

最新推荐文章于 2025-12-04 17:08:47 发布

原创最新推荐文章于 2025-12-04 17:08:47 发布 · 1.2k 阅读

CC 4.0 BY-SA版权

文章标签：

7 篇文章

订阅专栏

结构型设计模式关注的是如何将对象和类组装成更大的结构，同时保持结构的灵活性和高效性。它们主要用于处理类与对象之间的组合关系，帮助构建更易维护、扩展和复用的系统架构。

模式名称	核心思想概述
适配器模式（Adapter）	提供中间层，让接口不兼容的对象能够协作
桥接模式（Bridge）	将抽象与实现分离为两个独立层次，提高灵活性
组合模式（Composite）	“组合优于继承”，动态组装程序类的功能，常用于树形结构
装饰器模式（Decorator）	为对象动态添加新行为，通过封装扩展功能
外观模式（Facade）	为复杂系统/库提供简单统一的接口，隐藏内部复杂性
享元模式（Flyweight）	共享内存中的繁重部分，通过引用差异部分优化内存占用（高频用于游戏开发）
代理模式（Proxy）	提供原始对象的替代品或占位符，控制访问并可能对请求进行预处理

在游戏开发中，玩家可以使用多种输入设备操作游戏，例如：

每种设备有自己独立的输入接口方法：

但如果游戏逻辑层直接调用这些具体设备的输入方法，就需要为每种设备编写独立且冗余的代码，缺乏统一性，难以维护和扩展。

class InputDevice {
public:
    virtual void input() = 0; // 统一的输入方法
};

这些是原有的、接口不兼容的具体实现类，它们不能直接被游戏逻辑层统一调用。

我们为每种输入设备创建一个适配器类：
- KeyboardAdapter：继承自 InputDevice，内部包含一个 Keyboard 对象
- GamepadAdapter：继承自 InputDevice，内部包含一个 Gamepad 对象
适配器类的关键作用：
- 在构造函数中保存具体的输入设备对象（如键盘或手柄）
- 实现统一的 input() 方法，在方法内部调用具体设备的原始输入方法（如 pressKey() 或 pressButton()）

适配器就像一个“翻译官”，把具体设备的“语言”（pressKey / pressButton）翻译成目标接口的“通用语言”（input()）。

要素	说明	示例（输入设备场景）
目标接口（Target）	客户端期望使用的统一接口，简单易用	`InputDevice` 接口中的 `input()` 方法
原接口（Adaptee）	需要被适配的原有对象接口，通常与目标接口不兼容	`Keyboard::pressKey()` 和 `Gamepad::pressButton()`
适配器（Adapter）	实现目标接口，内部持有原接口对象，负责将原接口方法转换为统一的目标接口方法	`KeyboardAdapter` 和 `GamepadAdapter`

通过引入适配器，客户端代码与具体设备实现完全解耦，只需面向统一的接口编程，大大提高了系统的灵活性和可扩展性。

除了输入设备的兼容外，适配器模式在游戏及工业开发中还有其他常见应用：

背景：游戏策划使用 CSV、JSON、XML 等格式的策划表格配置游戏数据（任务、技能、剧情等），这些表格可能随着版本迭代发生变化。
问题：程序需要读取并解析这些不同格式的数据，而且每种格式的接口和结构可能差异较大。
解决方案：为每种数据格式创建一个适配器，统一封装解析逻辑，对外提供一致的接口。这样，无论策划使用哪种格式的表格，程序都能通过适配器无缝读取数据，无需修改核心逻辑。