HelloWorld 适配器模式教程

适配器模式把不兼容的接口“接头”起来：通过定义目标接口、保留现有实现（被适配者）并写一个适配器来做转换，HelloWorld 示例通常展示目标接口、被适配者与适配器三角关系，既能用继承做类适配，也能用组合实现对象适配，实践中重点是契约一致、职责单一、避免过度包装。

为什么需要适配器模式（用一句话理解）

想象你有一台旧打印机接口是并口，而新电脑只有 USB，适配器就是插在两者之间的转换器，使老设备在新环境下继续工作。软件里，当客户端代码期望一个接口，但已有类无法直接提供该接口时，适配器把已有实现“包裹/转换”为客户端期望的接口。

适配器模式的核心概念（费曼式分解）

把概念分解成最简单的部分

• 目标接口（Target）：客户端所期待使用的接口，例如 HelloService.sayHello()
• 被适配者（Adaptee）：现有实现，接口不匹配，但业务逻辑可用，例如 LegacyPrinter.printMsg()
• 适配器（Adapter）：实现目标接口并内部调用被适配者，完成接口转换

关键点：适配器不应该改变被适配者的业务逻辑，只做接口映射与必要的转换（参数、返回值、异常等）。

适配器模式的两种常见实现方式

• 类适配器（Class Adapter）：通过继承实现（在支持多重继承的语言中可行），适配器继承自被适配者并实现目标接口。
• 对象适配器（Object Adapter）：通过组合实现，适配器持有被适配者的实例并在目标接口方法中调用它。

何时选择哪种方式？

• 如果语言不支持多重继承（如 Java），优先使用对象适配器。
• 如果需要重用被适配者的大量实现并且继承不会造成语义冲突，可考虑类适配器。

HelloWorld 示例（三种语言对照）

下面用简化的 HelloWorld 例子演示适配器模式的变体：目标接口要求 hello() 返回字符串，但现有库提供 printHello() 直接输出或返回不同签名。

Java（对象适配器，常见）

// Target
public interface Hello {
    String hello();
}
// Adaptee
public class LegacyHello {
    public void printHello() { System.out.println("Hello from Legacy"); }
}
// Adapter
public class HelloAdapter implements Hello {
    private final LegacyHello legacy;
    public HelloAdapter(LegacyHello legacy) { this.legacy = legacy; }
    public String hello() {
        // 把 print 转为返回值（或其它变换）
        java.io.ByteArrayOutputStream baos = new java.io.ByteArrayOutputStream();
        java.io.PrintStream ps = new java.io.PrintStream(baos);
        java.io.PrintStream old = System.out;
        System.setOut(ps);
        legacy.printHello();
        System.out.flush();
        System.setOut(old);
        return baos.toString().trim();
    }
}

C++（类适配器，使用多重继承）

class IHello { public: virtual std::string hello() = 0; };
class LegacyHello { public: void printHello() { std::cout<<"Hello from Legacy\\n"; } };
// Adapter: 继承 LegacyHello 并实现 IHello
class HelloAdapter : public LegacyHello, public IHello {
public:
    std::string hello() override {
        std::ostringstream oss;
        // 假设把输出捕获或直接重用逻辑
        oss<<"Hello from Legacy";
        return oss.str();
    }
};

Python（鸭子类型与适配）

class Legacy:
    def print_hello(self):
        print("Hello from Legacy")

class HelloAdapter:
    def __init__(self, legacy):
        self.legacy = legacy
    def hello(self):
        from io import StringIO
        import sys
        buf = StringIO()
        old = sys.stdout
        sys.stdout = buf
        self.legacy.print_hello()
        sys.stdout = old
        return buf.getvalue().strip()

上面示例展示了如何把不同签名或不同行为的实现“包装”为统一的 hello()。注意实际工程中不要频繁用捕获输出的方式，最好修改被适配者或通过更清晰的转换逻辑。

UML 简要说明（口语化）

画一张简单的类图你就会懂：客户端—>Target（接口），适配器实现Target并持有或继承Adaptee。三个要素连成三角形。这个图不复杂，但说明了责任分配。

常见误区与反模式（要避免）

• 过度适配：每个小变化都写适配器会产生大量薄壳类，反而增加复杂度。
• 改变被适配者的职责：适配器只负责转换，若在适配器中加入大量业务逻辑，职责就混了，后续难以维护。
• 测试薄弱：把适配器当成黑盒，忽视契约测试，容易出现边界问题（参数、异常、并发）。

性能与测试建议（工程实践）

• 性能：适配器的开销通常来自额外的调用、数据转换或 I/O 捕获。对高性能路径请避免频繁的对象包装与复制。
• 测试：应有三类单测——目标接口行为测试、被适配者功能测试、以及适配器集成契约测试（参数边界、异常传递、并发场景）。
• 契约一致性：用契约测试（契约测试/Consumer Driven Contract）确保适配器对客户端暴露的行为与文档一致。

实际工程中的变体与结合模式

• 装饰者 vs 适配器：装饰者增强相同接口的行为，适配器转换接口。两者很容易混淆，关键看是否需要转换接口签名。
• Facade（外观）对比：外观提供简化的高层接口，适配器转换不兼容的低层接口，目标不同但有交集。
• 适配器链：有时需要多级适配器把多个不同接口逐步转换到目标接口，注意链条管理与故障定位成本。

简单的决策清单（快速上手）

• 先问：能否修改被适配者使其符合目标接口？若可以，优先修改，避免适配层。
• 若被适配者来自第三方或不可改动，使用对象适配器（组合）优先。
• 关注接口契约：输入、输出、异常、线程安全性都要在适配器层明确。
• 为每个适配器写集成契约测试，模拟真实客户端调用场景。

一个小表格：优缺点对比

常见问题（FAQ）

Q: 适配器会成为技术债吗？

A: 可能会，如果你频繁用适配器修补设计缺陷。良好的做法是将适配器作为过渡方案，长期看应评估是否重构或统一接口。

Q: 什么时候不该用适配器？

如果可以修改客户端或被适配者以统一接口，直接修改比增加适配层更清晰；如果适配器只是复制大量逻辑，说明设计需要重构而不是适配。

实践小贴士（那些不太正式但管用的经验）

• 给适配器写明确的文档：说明转换规则、边界条件与已知限制。
• 用小的、可测试的方法分解复杂的转换逻辑，便于单测覆盖。
• 避免在适配器里捕获所有异常并吞掉，要明确传递或包装异常以保留语义。
• 若适配器用于跨进程/跨语言的桥接，考虑序列化格式与版本兼容策略。

读书与参考（方便深入）

• Gamma, Helm, Johnson, Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software（GoF）
• Martin Fowler 等关于重构、集成模式的文章与书籍

写到这里，我其实还想补一句：适配器模式看似简单，但工程中它往往是连接旧与新的桥梁，设计时多想一步——这桥要不要长期保留，或者仅作过渡。就像把老家具接进新房间，有时候一块漂亮的接头就够了；有时候你得重做整套布局。本文里给出的是一条实用路径和检查点，照着做，能把 HelloWorld 的示例扩展到真实项目里去用掉。