GoF设计模式——适配器模式
h5打开以查看
为什么需要适配器模式？
写业务代码时经常碰到这种情况：项目里已经定义好了一个接口 PaymentGateway，所有支付都走它的 pay(orderId, amount) 方法；今天产品说要接入微信支付，打开 SDK 一看——微信用的是 unifiedOrder(body, outTradeNo, totalFee, ip)，参数和方法名跟系统的接口对不上。
// 系统希望的调用方式 paymentGateway.pay("ORD001", new BigDecimal("99.9")); // 但微信 SDK 实际上长这样 wxPayApi.unifiedOrder("商品", "ORD001", 9990, "127.0.0.1"); // 单位是分两种选择：把订单模块全部改成直接调微信 SDK，或者改微信 SDK 让它实现 PaymentGateway——前者一旦切换支付渠道就要重写业务代码，后者根本动不了第三方 SDK 的源码。
这种"现有的类"和"需要的接口"对不上的矛盾，就是适配器模式要解决的问题。
概念
适配器模式（Adapter Pattern）是一种结构型设计模式，核心思想是将一个类的接口转换成客户端期望的另一个接口，让原本不兼容的类能够协同工作。
适配器模式包含三个角色：
- Target（目标接口）：客户端期望使用的接口
- Adapter（适配器）：实现目标接口，内部持有被适配者，把目标接口的调用转换为被适配者的调用
- Adaptee（被适配者）：已有的类，其接口与目标接口不兼容，但功能正好是需要的
Adapter 实现 Target 接口并持有 Adaptee 实例，Client 只依赖 Target，完全不感知 Adaptee 的存在。Adapter 内部把 request() 翻译成 specificRequest()，参数和返回值的差异都在适配器里处理。
可以把适配器理解为电源转换头：新装的墙面插座只有两孔（系统期望的接口），家里的老电器是三脚插头（已有的、改不了的类），中间塞一个两脚转三脚的转换头——插座只看到两脚，老电器照样能用，"翻译"工作全在转换头内部完成。这个比喻贯穿后面的实现章节，方便对照理解。
实现
适配器模式有两种实现方式：对象适配器（组合）和类适配器（继承）。前者是 GoF 推荐方式，也是实际开发中最常用的；后者由于 Java 单继承限制，使用场景有限。
对象适配器
对象适配器通过组合实现：适配器实现目标接口，内部持有被适配者的引用，将调用委托给被适配者。
// 目标接口 public interface Target { public void request(); } // 被适配者 public class Adaptee { public void specificRequest() { System.out.println("Adaptee 的特定请求"); } } // 对象适配器：组合持有被适配者 public class Adapter implements Target { private Adaptee adaptee; public Adapter(Adaptee adaptee) { this.adaptee = adaptee; } @Override public void request() { adaptee.specificRequest(); } } // 客户端 Target target = new Adapter(new Adaptee()); target.request();引入一个例子：「家里的两孔插座，要给一台三脚插头的老电器供电，买一个两脚转三脚的电源转换头，一头插进插座、