适配器模式：接口转换让系统兼容

适配器模式的本质是“套一层薄壳”而非修改原有代码，它通过封装不兼容的旧类并提供客户期望的新接口，实现无缝协作——就像用转换器让中国两孔插头接入美式三孔插座一样自然；这种设计既避免了动已上线、被广泛依赖的第三方或遗留类所带来的高风险与高成本，又保证了客户端完全无感、可测试、可监控；但需警惕：一旦适配器变得臃肿、充斥类型判断或复杂转换逻辑，就说明问题已超出接口层面，真正需要的是架构重构而非缝合式适配。

适配器模式不是“改接口”，而是“套一层壳”让调用方感觉不到底层不兼容。

为什么不能直接改原有类的接口

现实里你根本没法动 AudioPlayer 或 Doc2007 这类已上线、被多处依赖的类：它可能来自第三方库、jar 包，或已被其他模块强耦合调用。强行改 playMp3() 方法签名，等于让所有调用方一起改代码——成本远高于加个适配器。

• 改原类 = 所有依赖方同步升级，风险高、周期长
• 加适配器 = 客户端只认 AdvancedAudioPlayer.play()，内部怎么转、转多少次，它完全不知道
• 适配器本身可测试、可替换、可日志埋点，不影响旧逻辑

适配器怎么做到“透明转换”

关键在客户端只依赖目标接口（如 Motor 或 IDoc2003），而适配器类（如 ElectricAdapter）同时满足两个条件：

• 实现目标接口（implements Motor），所以能被客户端当 Motor 用
• 持有适配者实例（private $emotor），把 drive() 调用转发给 $emotor->electricDrive()
• 转发时可做参数转换、格式封装、异常兜底——比如把 fileName + audioType 拆解后喂给 playMp3()

容易忽略的边界：适配器不是万能胶水

一旦发现要频繁在适配器里写大量 if-else 判断类型、做复杂数据转换、甚至补全缺失功能（比如 Doc2007 根本没有 print() 方法，硬在适配器里模拟），就该警觉了：

• 这已经不是接口适配，而是功能缝合——说明设计上存在断裂，该重构而不是硬适配
• 适配器里出现 convertVlcToMp3() 这种耗时操作，会掩盖真实性能瓶颈
• 如果多个适配器都包装同一个 Adaptee，且逻辑高度重复，说明缺一个统一的转换层，而非单个适配器问题

真正干净的适配器，代码通常很薄：几行委托、一两个字段、零业务逻辑。厚，往往意味着问题不在接口，而在架构。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~