C++怎么实现适配器模式_C++接口转换教程【兼容】

适配器模式在c++中应通过组合+委托实现，而非继承；核心是持有被适配对象并转发调用，避免类型判断、参数硬映射和异常吞没，注意生命周期、性能及语义清晰性。

适配器模式在 C++ 里不是靠继承“实现”，而是靠组合+委托

很多人一写 Adapter 就下意识让新类继承旧接口、再重写所有函数——这其实是“伪装成适配器的重构”，容易把责任耦合死，也违背了开闭原则。真正轻量、可复用的适配器，核心是持有被适配对象（Target 或 Adaptee）的引用或指针，把调用转过去。

常见错误现象：Adapter 类里大量重复 if/else 判断类型、手动映射参数顺序、把 Adaptee 的异常直接吞掉不转换。

• 使用场景：对接老 C 风格 API（如 int do_work(const char*, size_t)）到现代 C++ 接口（std::String_view + std::expected）
• 参数差异：注意 const 限定符传递（比如 Adaptee 接 const char*，但你传了 std::string& 的 c_str()，得确保生命周期够长）
• 性能影响：避免在 operator() 或频繁调用函数里做临时 std::string 构造；能用 std::string_view 就别用 std::string

std::function + Lambda 是最简适配器，但别滥用

当你只需要“把一个签名转成另一个”，比如把 int(int, int) 包一层变成 double(double, double)，std::function 加 lambda 一行就能搞定，比手写类快得多。

容易踩的坑：lambda 捕获了局部变量地址，但适配器对象活得比该变量久；或者忘了加 mutable 却在捕获中修改了值。

立即学习“C++免费学习笔记（深入）”；

示例：

auto add_ints = [](int a, int b) { return a + b; }; std::function<double(double, double)> add_doubles = [add_ints](double x, double y) {     return static_cast<double>(add_ints(static_cast<int>(x), static_cast<int>(y))); };

模板适配器要注意 SFINAE 和概念约束

泛型适配器（比如把任意 Container 适配成 Range）一旦放开模板参数，编译器可能在错误位置报一堆晦涩的 no matching function，而不是告诉你“你传的类型没 begin()”。这时候光靠 static_assert 不够，得用约束。

使用场景：封装第三方库容器（如 boost::container::static_vector）使其支持 for (auto& x : adapt(v))。

• 推荐用 requires（C++20）或 std::enable_if_t（C++17）筛掉非法类型
• 别在适配器构造函数里做 heavy 初始化（比如预分配内存），用户可能只拿它来声明变量
• 兼容性影响：GCC 10+ 对 requires 支持稳定；Clang 12+ 没问题；MSVC 19.29+ 才完整支持

多重继承适配器必须显式解决二义性

当你要同时适配两个有同名函数的接口（比如 Readable 和 Writable 都有 close()），用多重继承会触发编译错误：request for member ‘close’ is ambiguous。

这不是设计缺陷，是语言在提醒你：语义冲突必须人工裁定。

• 必须用作用域解析明确指定调用哪个基类的 close()，比如 Readable::close()
• 如果两个 close() 行为本质不同（一个刷缓冲区，一个释放句柄），就别硬塞进一个类——拆成两个独立适配器更安全
• 别依赖虚继承绕过二义性，那只会把调用路径变得更不可预测

适配器最难的从来不是语法，而是判断“哪部分逻辑该由适配器承担，哪部分该推给使用者”。比如错误码转换：是统一转成 std::error_code，还是保留原始整数并提供映射表？这个边界划错，后面所有人调用时都要猜。