gof-adapter

一句话概述

将一个接口转换为客户端期望的另一个接口，让原本因接口不兼容而无法协作的类能够协同工作。

何时使用此技能

• 集成第三方库，而它的接口与代码期望的接口不同。
• 从旧 API 迁移到新 API：编写一个适配器，以新接口实现旧接口（或反过来），然后逐步切换。
• 两个系统必须通信，但你无法更改其中任何一个：在它们之间放置一个适配器。
• 经典的适配器示例：电源插头适配器，让美式插头适配欧洲插座；底层电流相同，只有接口不同。

何时不使用此技能

• 两个接口服务于截然不同的概念目的——适配器会掩盖真正的领域决策，变成翻译工作；应明确呈现这一决策。
• 只需适配一个方法，而且宿主类可以修改为直接调用源对象——使用适配器属于过度设计。
• 包装器增加行为而不是改变接口——这属于 gof-decorator。
• 包装器隐藏子系统的复杂性——这属于 gof-facade。

核心内容

有两种结构变体：

对象适配器（最常见）。适配器持有被适配者实例的引用，并通过委托给它来实现目标接口。基于组合。适用于任何面向对象语言。

类适配器。适配器同时继承目标类和被适配者类（需要多重继承，因此除 C++ 外很少见）。基于子类化。

HFDP 中的典型示例是 Iterator / Enumeration 转换：旧代码返回 Enumeration；现代代码需要 Iterator。EnumerationIterator 适配器包装旧接口，并提供现代接口。

也存在双向适配器（同时满足两个接口并能双向转换的适配器），但它们会使接口面翻倍，通常不值得付出这份代价。

决策启发

• 在你的代码与外部代码的边界处构建适配器——绝不要放在领域内部深处。
• 让适配器保持精简：只实现代码实际用到的目标方法，而不是整个接口。
• 适配器是转换层；如果开始包含业务逻辑，这些业务逻辑就应该放在别处。

反模式

• “适配器作为集成层”——适配器逐渐承担了身份验证、重试、缓存和日志记录等工作。应将各项职责拆分出去。
• 适配器默默吞掉被适配者抛出的异常——适配器也必须转换错误。
• 为自己的代码编写适配器——如果两端都由你控制，就修改其中一端以匹配，而不是进行适配。

另请参阅

• gof-decorator——结构相似，但意图不同（装饰器增加行为；适配器改变接口）。
• gof-facade——将子系统（多个类）包装为更简单的接口时使用，而不是将单个类转换为不同接口。
• gof-proxy——控制对对象的访问时使用，而不是改变其接口。
• DDD ddd-context-mapping——防腐层是在限界上下文边界处的适配器。
• gof-kotlin-idioms——Kotlin 扩展函数可以充当单个方法的一次性适配器，无需引入类。

参考资料

• Head First Design Patterns（第 2 版），第 7 章（“Being Adaptive: the Adapter and Facade Patterns”）——权威章节，包含鸭子到火鸡的适配器示例。