面试官：对接又老又旧的第三方系统，你怎么保证新业务代码不被污染？

很多同学在做项目或者实习的时候，都会碰到一个让人头疼的活儿：对接第三方系统。

尤其是那种又老又旧的系统，比如某个银行的古董级支付网关。你现在的项目全是 Spring Boot + JSON，结果对面偏偏要求传一个结构极其诡异的 XML，还会返回一堆不知所云的错误码。

很多新手的做法是：不管三七二十一，直接在自己的OrderService（订单服务）里引入对面的 SDK，一边拼接 XML，一边处理业务逻辑。最后代码写得像一坨乱麻。

哪天如果换了一家支付公司，或者对面终于升级成了 JSON 接口，你的OrderService就要面临伤筋动骨的大改。改出线上 bug，绩效直接就没了。

怎么解决这种问题？其实这就是**适配器模式（Adapter Pattern）**最经典的用武之地。

核心机制：插个“转接头”

生活里，你的电脑只有 Type-C 接口，但公司的投影仪只有 HDMI 线。你怎么连？你肯定不会去拆电脑的主板，也不会把投影仪的线剪断重接，而是买一个Type-C 转 HDMI 的扩展坞。

在代码里也是一样。新系统有新系统的接口规范（Type-C），老系统有老系统的方法（HDMI）。我们只需要写一个中间类（扩展坞）把老系统的调用包装起来，转换成新系统认识的样子。这就是适配器。

实战推演：远离代码污染

为了说明白，我们看个极简的例子。假设你们系统内部统一要求的支付网关接口长这样：

// 新系统统一期望的接口publicinterfaceModernPaymentGateway{booleanpay(StringorderId,doubleamount);}

但是，你要对接的那个老银行系统，人家提供的类是这样的：

// 别人提供的老旧 SDK，你没法修改它的代码publicclassOldBankSdk{publicvoidsubmitTransaction(StringxmlData){// 极其复杂的 XML 组装和网络请求System.out.println("向老系统发送 XML: "+xmlData);}}

如果你直接在核心业务层里去实例化OldBankSdk并调用，就等于把主板拆了去硬接 HDMI。所以我们来写个适配器：

// 适配器：实现你想要的接口，内部去调用老系统的代码publicclassBankPaymentAdapterimplementsModernPaymentGateway{// 组合进来：把老系统的类当作自己的成员变量privateOldBankSdkoldBankSdk;publicBankPaymentAdapter(OldBankSdkoldBankSdk){this.oldBankSdk=oldBankSdk;}@Overridepublicbooleanpay(StringorderId,doubleamount){// 1. 将新系统的数据结构转换为老系统需要的格式（XML）Stringxml=String.format("<order><id>%s</id><money>%f</money></order>",orderId,amount);// 2. 调用老系统的真实逻辑try{oldBankSdk.submitTransaction(xml);returntrue;}catch(Exceptione){// 3. 转换老系统的异常为新系统的异常或状态returnfalse;}}}

你看，现在你的核心业务层，只需要注入ModernPaymentGateway就行了。它压根不知道底层用的是 XML 还是 JSON，也不知道对接的是老银行还是新微信。代码解耦得干干净净。

顺便提一句，这就叫对象适配器（通过组合的方式）。还有一种叫类适配器（通过继承），但在实际开发里极少用。因为 Java 是单继承，把宝贵的继承位浪费在一个外接系统上非常蠢。组合优于继承，这是死理。

在面试中怎么聊适配器模式？

很多同学背八股文，面试官一问适配器，上来就是：“适配器模式分为 Target、Adaptee、Adapter 三个角色……” 这种回答干瘪且毫无杀伤力。

高级的答法是结合场景说痛点。你可以这么聊：

“在之前的项目里，我们需要接入第三方的服务（比如通知、支付等）。为了防止第三方 SDK 的数据结构污染我们核心的领域模型，我没有直接在 Service 层调用它们。

我先根据我们的业务需求定义了一个标准 Interface（比如上面的ModernPaymentGateway），然后写了一个 Adapter 去实现这个接口，在 Adapter 内部完成参数组装和第三方 API 的调用。

这样做的好处是符合开闭原则（OCP）。后续如果第三方服务商的 API 发生破坏性升级，或者我们要替换成另外一家服务商，核心业务逻辑一行代码都不用改，只需要新增或者修改这个具体的 Adapter 就可以了。”

这段话说出来，面试官就知道你不仅背过概念，更是真正挨过毒打、做过设计的。

避坑指南：什么时候千万别用？

最后说个大实话：适配器模式本质上是一种“补救措施”，是一块遮羞布。

如果这是个历史遗留系统，或者没法控制的第三方依赖，你用适配器去包装它，那叫优雅。

但如果你们是几个同事在一起从零开发新系统，前后端或者两个微服务之间因为沟通不到位，导致接口参数对不上，这时候谁要是敢提议“我们写个适配器转接一下吧”……

千万别手软，直接骂他。这时候该干的事情是赶紧把接口规范统一，而不是写个适配器去掩盖设计初期的失误。