面试官对接又老又旧的第三方系统你怎么保证新业务代码不被污染很多同学在做项目或者实习的时候都会碰到一个让人头疼的活儿对接第三方系统。尤其是那种又老又旧的系统比如某个银行的古董级支付网关。你现在的项目全是 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.oldBankSdkoldBankSdk;}Overridepublicbooleanpay(StringorderId,doubleamount){// 1. 将新系统的数据结构转换为老系统需要的格式XMLStringxmlString.format(orderid%s/idmoney%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 就可以了。”这段话说出来面试官就知道你不仅背过概念更是真正挨过毒打、做过设计的。避坑指南什么时候千万别用最后说个大实话适配器模式本质上是一种“补救措施”是一块遮羞布。如果这是个历史遗留系统或者没法控制的第三方依赖你用适配器去包装它那叫优雅。但如果你们是几个同事在一起从零开发新系统前后端或者两个微服务之间因为沟通不到位导致接口参数对不上这时候谁要是敢提议“我们写个适配器转接一下吧”……千万别手软直接骂他。这时候该干的事情是赶紧把接口规范统一而不是写个适配器去掩盖设计初期的失误。