适配器模式通过新建适配器类实现目标接口并组合适配者，使新旧系统解耦交互；优先用对象适配器避免单继承限制；双向场景需双向接口映射且防循环依赖；上线前须验证客户端不依赖适配者、移除适配者后仍可编译、适配器逻辑可被mock测试。

适配器模式不是为了改代码，而是让新旧系统“说同一种话”。它不碰原有逻辑，只在中间搭一座桥——目标接口照用，旧类照搬，彼此互不干扰。

明确三类核心角色，避免混淆

写适配器前先理清谁是谁：

• 目标接口（Target）：新系统里客户端直接调用的接口，比如 pay(String orderId, double amount)，是统一入口，不能动；
• 适配者（Adaptee）：已存在的老类或第三方类，比如 LegacyPayment，它有 payOld(...) 方法，但你无权改、也不该改；
• 适配器（Adapter）：新建的类，实现目标接口，内部持有适配者实例，把 pay(...) 的调用转成 payOld(...) 的执行。

优先用对象适配器，避开继承陷阱

Java、C# 等单继承语言中，类适配器需同时继承目标抽象类和适配者类，实际受限大、可读性差。对象适配器更自然、更安全：

• 适配器类 实现目标接口，不继承任何业务类；
• 通过构造函数或 setter 注入适配者实例，用组合关系复用功能；
• 后续替换适配者（比如从 LegacyPayment 换成 ThirdPartyPaySDK），只需换实例，适配器主体不用动。

适配不止单向，双向场景要留余地

有些集成需要新旧系统互相调用，比如新系统发指令，旧系统回状态，旧系统也需触发新事件。这时可设计双向适配器：

• 适配器同时实现两个接口，比如 NewService 和 OldService；
• 内部维护双向映射逻辑，例如把 newMethod() 转为 oldMethod()，再把 oldCallback() 包装成 onNewEvent() 推出；
• 注意避免循环依赖——适配器不直接引用新系统或旧系统的高层模块，只对接契约接口。

上线前检查三个关键点

一个适配器是否真正解耦，看这三点是否落地：

• 客户端代码 完全不 import 适配者类，只依赖目标接口；
• 适配者类的 jar 或源码被移除后，编译仍通过（只要适配器还在）；
• 单元测试中，可用 mock 替换适配者实例，验证适配器转发逻辑是否准确，不牵扯真实支付或网络调用。