写这篇的时候我正在帮一个老系统做接口迁移。系统里有个日志模块原本只负责把日志写到本地文件现在要对接新的统一日志平台走HTTP上报。按常规思路得改老模块的代码可这个模块被好几个业务方直接依赖改接口签名等于把所有调用方全拉下水。于是我打开编辑器写下了一个Adapter类十几行代码两边都没动问题就解决了。这就是今天要聊的适配器模式——专门处理已有类接口不兼容的问题最常见的两种实现路线就是靠继承的分类适配器和靠组合的对象适配器。很多人学设计模式的时候看到“适配器”三个字觉得简单真上手还是容易迷糊什么时候该继承什么时候该组合为什么都说组合优先可教科书里分类适配器也给了代码这篇文章会把两种实现拆开揉碎从原理到代码到调试用同一个日志上报场景从头到尾走一遍。看完你就能明白适配器选型不是靠背规则而是看你的“已有类”到底能改多少、不能改多少。1. 适配器模式到底在解决什么问题接口不兼容与“转接头”思维1.1 为什么已有类接口会不兼容版本演进与职责边界先认识一下问题的根源。所谓“已有类接口不兼容”本质上是因为两个对象对“方法长相”的预期不一致。系统A里有一个类定义了自己的方法名、参数顺序、返回类型系统B需要调用某个功能但B期待的是一个完全不同的方法签名。两边都不愿意改因为改了A会影响一批老调用方改了B会让新代码迁就旧设计。这种不一致在真实项目里太常见了。第三方SDK升级是重灾区比如某个消息中间件的客户端从旧版本切到新版本推送方法从sendMessage(String topic, String body)变成了send(String topic, byte[] body)而你们的业务代码大量调用了旧方法。再比如公司内部服务重构服务接口从 Dubbo 协议换成 HTTP 协议参数从 Java 对象变成 JSON 字符串。这些场景的共同点是接口本身设计得没问题只是升级了、变化了你不能要求所有上游业务立刻跟着改。还有一种情况是职责边界问题。你拿到一个别人维护的工具类功能正好是你需要的但它的方法设计得和你当前模块的抽象层不一致。直接依赖它吧你的业务代码里会到处出现“低级别API”以后换实现很痛苦不改它吧又没法用。这时候适配器就派上用场了它像一个中间层把低级别的已有类包装成符合你团队标准的高级接口。1.2 适配器模式的核心思想让不该耦合的双方通过中转协作用个生活里的例子你马上明白。手机充电器插头是两脚的墙上插座是三孔的你直接怼不进去需要用一个转接头。转接头的左边是两脚插孔右边是三脚插头它把两边不同的物理形态连接起来谁都不用改。适配器模式就是这个转接头。在面向对象设计里适配器的核心思想是引入一个中间类让“客户端”和“被适配者”各自保持原样通过中间类实现协作。这里遵循了两个非常重要的设计原则。第一是开闭原则——对扩展开放对修改关闭。你不需要去改已有类的源码只需要新增一个适配器类就完成了接口转换。第二是单一职责原则——适配器只负责“格式转换”不负责业务逻辑它把“怎么调用旧类”这一细节从客户端手里拿走了。这意味着解耦的边界非常重要。适配器的存在让你可以自由替换底层实现。比如今天被适配的是“写文件日志”明天换成“发HTTP日志”只要你的目标接口不变客户端代码一行都不用动只是换一个Adapter对象而已。1.3 一个能落地的场景模型日志上报接口为了后面两种实现能够对比我们固定一个场景。你的项目里有一个旧的日志实现类长这样public class FileLogger { public void writeToFile(String level, String message) { // 打开文件、追加日志 System.out.println(文件日志: [ level ] message); } }这个类已经运行了三年内部有各种文件锁、格式处理逻辑不能动。而你的业务层现在希望面向一个更干净的接口比如public interface LogTarget { void log(String level, String message); }为什么不用旧类直接调因为业务层不想知道什么叫“writeToFile”它只关心“log”这个行为。如果以后日志库换成别的实现业务层也不受影响。现在要做的就是写一个适配器让FileLogger这个“已有类”通过LogTarget这个“目标接口”被调用。接下来分别用分类适配器和对象适配器来实现。2. 分类适配器用继承实现把“旧类”直接包装成“新接口”2.1 继承怎么实现适配类Synchronous外层继承旧类并实现新接口分类适配器有的地方也叫类适配器它的实现方式非常直观创建一个新类让它去继承被适配者已有类同时实现目标接口。这样新类天然拥有被适配者的所有公开方法和属性同时又满足目标接口的签名要求。这里的关键在于Java是单继承所以分类适配器只能继承一个类。如果你不需要同时继承多个旧类这种写法就足够干净。它的结构很清晰目标接口定义的是“标准”继承的旧类提供“实现”适配器自己负责把目标接口的方法调用转换成对父类方法的调用。用代码来说就是这样的骨架public class FileLoggerAdapter extends FileLogger implements LogTarget { Override public void log(String level, String message) { // 把新接口的方法转换成父类方法 writeToFile(level, message); } }这里FileLoggerAdapter就是分类适配器。它从父类FileLogger继承了writeToFile又通过implements LogTarget保证了可以被业务层当作LogTarget来使用。业务层眼里它就是一个LogTarget而内部实际干活的是继承自FileLogger的方法。2.2 分类适配器的适用场景与利弊分类适配器有两个非常明显的好处。第一是代码量少如果一个旧类的方法很多你只需要在自己关心的方法上做“重命名”其他不想动的方法可以原样继承不会被强制暴露成一个“多余的中转方法”。第二是它可以覆盖父类的方法如果你对旧类的某个方法不满意在适配器里重写它就行了旧类的源码依然不用动。但坏处也很致命。首先是Java单继承的限制如果你的适配器还想继承其他类就无法实现。其次继承会让适配器和被适配者形成强绑定父类的方法和内部状态全都会暴露给适配器如果父类的构造方法需要参数适配器就必须显式调用super(...)这会让适配器的创建依赖于父类的内部构造。第三继承破坏了封装性父类内部实现细节一旦变化适配器可能无声无息地跟随变化。换个角度说分类适配器其实引入了“一个类同时属于两个类型体系”的交叉容易让人困惑。所以分类适配器比较适合这样的场景被适配者是你完全可控的类你只想给它“换个马甲”目标接口的方法和被适配者的方法数量接近转换逻辑简单你不需要适配多个旧类也不需要保留旧类的原始行为。换句话说它适合“快速给旧类做一个新身份”的场景。2.3 分类适配器实例演示旧日志类转化为新日志接口回到日志场景完整看一下分类适配器的代码。首先是被适配者老文件日志类我们当成“已有类”坚决不改public class FileLogger { public void writeToFile(String level, String message) { String line String.format(%s %s %s%n, java.time.LocalDateTime.now(), level, message); System.out.print(line); // 模拟写文件 } }然后是目标接口public interface LogTarget { void log(String level, String message); }接着是分类适配器public class FileLogAdapter extends FileLogger implements LogTarget { Override public void log(String level, String message) { // 这里可以加一层格式整理 writeToFile(level, message); } }最后是客户端调用public class Client { public static void main(String[] args) { LogTarget logger new FileLogAdapter(); logger.log(INFO, 用户登录成功); } }你发现没有Client里只用LogTarget它甚至不知道FileLogger的存在。如果以后需要换成数据库日志只需要再写一个DbLogAdapter然后把LogTarget logger new DbLogAdapter()即可。这个例子也展示了分类适配器的典型用法——继承FileLogger实现LogTarget通过log方法调用父类的writeToFile。代码虽然简单但它能跑通是因为适配器本身同时满足了两个抽象继承了老类的能力又符合新接口的约束。3. 对象适配器用组合实现把“旧类”作为成员变量注入3.1 组合为什么更灵活持有被适配对象而不是继承它对象适配器是头脑清晰的设计师通常默认的选择它的核心变化在于不继承被适配者而是把被适配者作为一个成员变量放进来。适配器实现目标接口内部持有被适配者对象在接口方法里调用这个被持有对象的方法。术语上把这种关系称为“组合”也就是“有一个”的关系而不是“是一个”的关系。这个转变非常关键。继承意味着你“成为”了那个旧类你必须接受它的所有属性、方法、可见性你被绑死在单一祖先上。组合意味着你“拥有”那个旧类你可以决定什么时候调用它、调用它的哪几个方法、甚至完全不调用它。组合同时解除了单继承的束缚一个适配器可以持有多个被适配对象分别处理它们的转换逻辑。还是拿日志例子来看对象适配器的骨架是这样的public class FileLoggerAdapter implements LogTarget { private final FileLogger fileLogger; public FileLoggerAdapter(FileLogger fileLogger) { this.fileLogger fileLogger; } Override public void log(String level, String message) { fileLogger.writeToFile(level, message); } }可以看到适配器不再继承FileLogger而是在构造时接收一个外部传入的FileLogger实例。业务层创建适配器的时候会先把旧对象构造出来传进来FileLogger fileLogger new FileLogger(); LogTarget logger new FileLoggerAdapter(fileLogger); logger.log(INFO, 用户登录成功);3.2 对象适配器的亮点与代价对象适配器在工程里更受欢迎理由很充分。第一它尊重封装。适配器只通过被适配者的公开方法去调用它不关心它的内部继承树也不强制建立父子关系。第二它非常灵活。你可以为一个被适配者实现多个目标接口也可以反过来让一个适配器持有多个被适配者把它们组合成新的行为。第三它和装饰器模式、代理模式更容易区分因为组合本来就是面向对象设计中比继承更受推崇的关系。当然对象适配器也有自己的代价。最直观的是需要手动多写一个构造方法和成员变量代码量会比分类适配器多一些。另外如果你需要对被适配者的“所有方法”都做一层转换组合模式下你要把每个方法都包一遍继承模式下这些方法会直接暴露反而不需要额外写。再有对象适配器在创建时依赖外部传入被适配者如果被适配者的构造逻辑很复杂创建流程会稍显繁琐。你会发现所谓“代价”其实是设计上的取舍。继承式的快捷是建立在强耦合上的组合式的繁琐换来了松耦合。真正需要为对象适配器多付的成本也就是那几行代码跟它换来的可维护性比起来简直不值一提。3.3 对象适配器实例演示同样的日志需求换种写法为了让对比更直观我们把上一个日志例子用对象适配器重写一遍。被适配者和目标接口保持完全一样不重复贴了直接看适配器public class FileLoggerAdapter implements LogTarget { private final FileLogger fileLogger; public FileLoggerAdapter(FileLogger fileLogger) { this.fileLogger fileLogger; } Override public void log(String level, String message) { // 可以做格式转换比如统一大写 String normalizedLevel level null ? INFO : level.toUpperCase(); fileLogger.writeToFile(normalizedLevel, message); } }客户端使用public class Client { public static void main(String[] args) { FileLogger fileLogger new FileLogger(); LogTarget logger new FileLoggerAdapter(fileLogger); logger.log(info, 用户登录成功); } }注意这里我故意传了小写的info适配器负责把它转成大写这就是一种“适配”——不仅仅是重命名方法还可以处理接口之间的参数语义差异。如果将来要把日志发给外部平台外部平台要求的格式可能完全不同你只要在log方法里改写适配逻辑客户端不用感知。对象适配器还有一个很加分的特点它支持“延迟创建”和“共享复用”。比如你可以在适配器内部持有多个被适配者根据参数决定调用哪一个public class SmartLogAdapter implements LogTarget { private final FileLogger fileLogger; private final HttpLogger httpLogger; public SmartLogAdapter(FileLogger fileLogger, HttpLogger httpLogger) { this.fileLogger fileLogger; this.httpLogger httpLogger; } Override public void log(String level, String message) { if (ERROR.equals(level)) { httpLogger.send(level, message); // 错误日志走网络 } else { fileLogger.writeToFile(level, message); // 普通日志写文件 } } }这种“多被适配者”的能力是分类适配器做不到的因为它只能继承一个父类。4. 分类适配器 vs 对象适配器一图看懂区别与选择标准4.1 关键差异对照表很多初学设计模式的人会陷入一个误区非黑即白地判断哪种适配器更好。其实两者解决的痛点一样只是实现策略不同各有适用土壤。我把关键差异整理成一张表方便你对照对比维度分类适配器继承实现对象适配器组合实现实现方式继承被适配者并实现目标接口持有被适配者实例并实现目标接口关系类型“是一个”的继承关系“有一个”的组合关系与旧类耦合度高父类变化会影响适配器低只依赖公开方法是否需要手动创建被适配者不需要通过super构造需要通过构造传入或内部创建能否适配多个旧类不能Java单继承能可持有多个被适配者能否自动暴露旧类额外方法能子类自动继承不能未包装的方法不暴露能否重写被适配者行为能直接覆盖父类方法能在方法体里决定是否调用旧逻辑代码量较少略多对调用方透明性透明透明推荐程度少用默认推荐这里“推荐程度”我直接写了少用和默认推荐。原因前面也说了继承本身就是一种比组合更脆弱的复用方式。但教材里仍然保留分类适配器是因为它确实在某些限制条件下有存在意义比如你无法修改被适配者的构造方式又希望快速满足一个新接口。4.2 选择指南什么时候用继承式什么时候用组合式选择其实可以量化成一个决策流程。你先问自己三个问题第一个问题我需要适配的“已有类”是不是只有一个如果是多个直接放弃分类适配器因为单继承装不下多个父类。只能选择对象适配器在适配器里同时持有多个旧对象。第二个问题我是否需要“原样复用”被适配者的所有公开方法如果目标接口几乎和被适配者的方法完全一致只是改了类名、方法名那么分类适配器可以少写很多包装代码。但这种情况其实是少数更多时候目标接口是经过抽象精简的只需要用到旧类的一部分能力对象适配器更合适。第三个问题被适配者的构造过程是否复杂如果它的构造需要一堆参数而且这些参数在适配器内部就能准备好那么分类适配器可以通过super(...)来构造。但如果你希望把构建细节留给调用方组合式更自然因为调用方可以先创建被适配者再告诉适配器。我个人的默认选择是除非有非常明确的理由需要继承否则一律用对象适配器。这一条不仅适用于适配器模式几乎适用于所有“两种关系都可以实现”的设计抉择。组合带来的解耦和弹性可以帮你省掉未来大量改代码的时间。5. 实操过程从零实现一个安全的适配器完整步骤5.1 步骤一定义目标接口看清“标准”动手写适配器之前先别急着操作被适配者第一步是把“目标接口”看清楚。这个接口是你业务层希望使用的标准它有可能是你自己定义的也有可能是第三方框架要求的。无论哪种你要把它视为“稳定的协议”。实际操作时我会先打开接口文档把每个方法的入参、返回值、异常声明、语义全都列出来。比如LogTarget.log(String level, String message)这个方法的level到底传什么范围是INFO/ERROR还是任意字符串message要不要做编码这些细节决定了适配器内部是否需要做转换。不要太相信接口注释最好找出至少两三个真实调用案例看看业务方是怎么用这个接口的。这样做的目的是防止你把适配器写成了“把A方法改成B方法”的形式化代码却忽略了语义层面的差异。如果目标接口允许抛异常但被适配者不会抛你的适配器就得决定是吞掉异常还是包装成运行时异常。5.2 步骤二确定被适配者梳理方法映射第二步把要适配的旧类的方法梳理出来。这一步要列出被适配者的所有公开方法以及目标接口的方法然后做一个映射表。映射不是简单的一一对应有些目标接口方法可能不需要用到被适配者直接返回默认值有些目标接口方法可能要用到被适配者多个方法组合。我在做日志适配的时候就整理过一张表目标接口方法被适配者方法转换逻辑log(String level, String message)writeToFile(String level, String message)直接把参数透传level统一转大写flush()flushAndClose()只调一次flushAndClose忽略返回值close()closeWriter()包装为无返回值这张表的价值不只是给自己看更是后期写单元测试的依据。你可以针对表格里的每个映射写一条测试用例确保每个目标接口方法的行为符合预期。5.3 步骤三选择适配策略并编写Adapter到了这一步才考虑用分类还是对象适配器。判断依据就是前面第4节说的决策问题。默认选对象适配器。下面我以对象适配器为例给出一个更完整的实现。假设被适配者还有关闭和刷新方法public class FileLogger { public void writeToFile(String level, String message) { System.out.println(文件日志: [ level ] message); } public void flushAndClose() { // 模拟刷新并关闭 System.out.println(文件日志: 已刷新并关闭); } }目标接口扩展为三个方法public interface LogTarget { void log(String level, String message); void flush(); void close(); }对象适配器实现public class FileLoggerAdapter implements LogTarget { private final FileLogger fileLogger; public FileLoggerAdapter(FileLogger fileLogger) { this.fileLogger fileLogger; } Override public void log(String level, String message) { String normalized level null ? INFO : level.toUpperCase(); fileLogger.writeToFile(normalized, message); } Override public void flush() { // 这里目标接口不想暴露flushAndClose的AndClose语义 // 可以通过重载的方式只刷新比如调用一个只刷新的方法 // 假设FileLogger有flushOnly()这里就调它 } Override public void close() { fileLogger.flushAndClose(); } }这个例子里flush方法的处理有点取巧如果FileLogger没有单独的flushOnly方法适配器需要自己决定语义。这里要强调适配器可以调整方法粒度但不要让适配器私自去猜测旧类的意图。如果旧类没有提供对应能力宁可让适配器调用一个“最接近”的方法并在注释里说清楚也不要为了凑方法签名而瞎写。5.4 步骤四测试兼容性与边界情况适配器写完后测试是最容易被忽略的环节。许多人只测“正常路径”传一个正常参数看到能打印就完事了。这样不够适配器最容易出错的地方恰恰是边界情况。我常用的测试清单包括四类参数为空时怎么处理参数格式非法时是否抛异常异常在被适配者内部抛出时适配器是透传还是包装适配器是否被并发调用目标接口和被适配者的线程安全性是否匹配。拿日志适配器来说level传null时适配器要决定是否给默认值。message传null时被适配者能不能接受如果不能适配器最好主动抛IllegalArgumentException不要让NullPointerException从深层冒出来这样排查起来更痛苦。还有并发场景如果FileLogger不是线程安全的而业务层是并发打日志适配器里应该加锁否则会实际运行中产生日志交错或数据丢失。5.5 实战中容易踩的坑空指针、循环调用、异常吞掉根据我的排查经验适配器模式在实战中有三个高频坑。第一个坑是空指针。构造适配器时忘了传被适配者或者被适配者在某个方法里返回了null而适配器没有判空。我建议在构造函数里就校验如果传入为null直接抛NullPointerException让问题尽早暴露。public FileLoggerAdapter(FileLogger fileLogger) { if (fileLogger null) { throw new IllegalArgumentException(fileLogger must not be null); } this.fileLogger fileLogger; }第二个坑是循环调用。有些适配器为了“同时适配两个方向”会在被适配者的方法里又调用适配器结果形成无限递归。这个在代码复审时尤其要小心。解决方法很简单适配器只做单向转换双向转换拆成两个独立的适配器类。第三个坑是异常吞掉。有些同学为了让调用方“无感”在适配器里写了大大的try-catch然后把异常打印一下就吞掉了。这在业务里埋雷因为调用方如果依赖某个方法的返回值或者异常来感知失败吞掉异常等于静默失败。适配器可以在合适的抽象层做异常包装但不要无条件吞掉。比如把受检异常转换成运行时异常是可以接受的但直接catch (Exception e) {}就要警惕。6. 常见问题与排查技巧实录6.1 为什么适配器里调不到被适配者的私有方法这个问题经常出现在分类适配器里。分类适配器通过继承获得了被适配者的公开和受保护方法但私有方法还是拿不到。这其实是好事因为适配器不应该依赖私有方法。如果你真的需要访问某个私有逻辑可以考虑把这些方法提升为protected或者把该逻辑抽象成一个独立的组件。更推荐的做法是改去组合让适配器通过公开方法访问调用方负责把旧类实例传进来。6.2 适配器和装饰器模式长得像怎么区分两个模式都涉及“把一个对象包起来”的结构但目的完全不同。适配器是为了“转换接口”让原来不兼容的接口可以在一起工作装饰器是为了“增强行为”在保持原接口不变的前提下给对象添加新职责。怎么辨别看目标接口。如果包装后的对象暴露的接口和原来不一样那是适配器如果包装后的对象暴露的接口和原来一样只是加了点功能那是装饰器。比如LogTarget和FileLogger的接口不同所以是适配器如果还是叫FileLogger接口只是给日志加了加密那就是装饰器。6.3 适配器模式会不会影响性能适配器本身多一层方法调用对绝大多数业务系统来说这层调用带来的性能损耗可以忽略不计。真正要注意的是不要在适配器里面做重活。有些同事会把数据转换逻辑放到适配器里比如把消息体从XML转成JSON这个操作本身可能很耗时适配器只是“编排”不是“执行者”。如果你发现适配器耗时高先看是适配器自己做了转换还是调用了被适配者的重逻辑。后者跟你没关系前者你就应该把转换逻辑拆出去。6.4 一个适配器可以同时适配多个旧类吗可以。对象适配器天然支持“多被适配者”你可以在一个适配器里持有两个甚至多个旧类实例。但注意要控制复杂度如果适配器内部逻辑超过两个分支建议拆分。分类适配器做不到多父类所以这种需求下只能选对象适配器。6.5 代码审查时怎么快速判断适配器写得好不好我复审其他人的适配器代码时会看这几点第一是否修改了被适配者源码。如果改了说明这不该叫适配器了应该叫“重构老类”。第二适配器内部是否存在业务规则。如果一段规则写在适配器里且未来可能在多个地方复用这段规则就应该抽出来。第三异常处理是否合理。第四适配器是否承担了它不该承担的职责比如又做接口转换又做日志记录又做性能统计这种“万能适配器”就需要拆。7. 最后的实操心得关于适配器模式我最想说的是别把适配器当成“补丁”的代名词。优秀的适配器是提前规划好的防腐层它保护你的业务代码不依赖外部变化糟糕的适配器则是四处打补丁谁改都往里塞逻辑最后变成一团浆糊。我的习惯是每写一个适配器就给它配一个对应的单元测试测试里写明“被适配者的语义”和“目标接口的语义”之间的映射关系这样以后即使替换被适配者单元测试也能立刻告诉我们哪些语义被破坏了。还有个小技巧想分享当你不得不在“继承”和“组合”之间犹豫时试着把适配器的名字写出来。如果名字里包含“文件”“日志”“HTTP”这种具体实现词说明适配器和被适配者绑得太紧考虑换成组合式让适配器通过构造参数接收实现反而更有弹性。反过来如果只是极少数的临时转换分类适配器能省你三分钟那用也无妨。说到底适配器模式就是一场关于“边界”的修炼。你自己需要想清楚哪里是老代码的边界哪里是新接口的边界而适配器就是那个站在边界的联络员。写它之前多问自己一句这个转接头是真的需要还是我设计上偷懒了想清楚这一点你的代码会比绝大多数教科书示例都要健壮。
写这篇的时候我正在帮一个老系统做接口迁移。系统里有个日志模块原本只负责把日志写到本地文件现在要对接新的统一日志平台走HTTP上报。按常规思路得改老模块的代码可这个模块被好几个业务方直接依赖改接口签名等于把所有调用方全拉下水。于是我打开编辑器写下了一个Adapter类十几行代码两边都没动问题就解决了。这就是今天要聊的适配器模式——专门处理已有类接口不兼容的问题最常见的两种实现路线就是靠继承的分类适配器和靠组合的对象适配器。很多人学设计模式的时候看到“适配器”三个字觉得简单真上手还是容易迷糊什么时候该继承什么时候该组合为什么都说组合优先可教科书里分类适配器也给了代码这篇文章会把两种实现拆开揉碎从原理到代码到调试用同一个日志上报场景从头到尾走一遍。看完你就能明白适配器选型不是靠背规则而是看你的“已有类”到底能改多少、不能改多少。1. 适配器模式到底在解决什么问题接口不兼容与“转接头”思维1.1 为什么已有类接口会不兼容版本演进与职责边界先认识一下问题的根源。所谓“已有类接口不兼容”本质上是因为两个对象对“方法长相”的预期不一致。系统A里有一个类定义了自己的方法名、参数顺序、返回类型系统B需要调用某个功能但B期待的是一个完全不同的方法签名。两边都不愿意改因为改了A会影响一批老调用方改了B会让新代码迁就旧设计。这种不一致在真实项目里太常见了。第三方SDK升级是重灾区比如某个消息中间件的客户端从旧版本切到新版本推送方法从sendMessage(String topic, String body)变成了send(String topic, byte[] body)而你们的业务代码大量调用了旧方法。再比如公司内部服务重构服务接口从 Dubbo 协议换成 HTTP 协议参数从 Java 对象变成 JSON 字符串。这些场景的共同点是接口本身设计得没问题只是升级了、变化了你不能要求所有上游业务立刻跟着改。还有一种情况是职责边界问题。你拿到一个别人维护的工具类功能正好是你需要的但它的方法设计得和你当前模块的抽象层不一致。直接依赖它吧你的业务代码里会到处出现“低级别API”以后换实现很痛苦不改它吧又没法用。这时候适配器就派上用场了它像一个中间层把低级别的已有类包装成符合你团队标准的高级接口。1.2 适配器模式的核心思想让不该耦合的双方通过中转协作用个生活里的例子你马上明白。手机充电器插头是两脚的墙上插座是三孔的你直接怼不进去需要用一个转接头。转接头的左边是两脚插孔右边是三脚插头它把两边不同的物理形态连接起来谁都不用改。适配器模式就是这个转接头。在面向对象设计里适配器的核心思想是引入一个中间类让“客户端”和“被适配者”各自保持原样通过中间类实现协作。这里遵循了两个非常重要的设计原则。第一是开闭原则——对扩展开放对修改关闭。你不需要去改已有类的源码只需要新增一个适配器类就完成了接口转换。第二是单一职责原则——适配器只负责“格式转换”不负责业务逻辑它把“怎么调用旧类”这一细节从客户端手里拿走了。这意味着解耦的边界非常重要。适配器的存在让你可以自由替换底层实现。比如今天被适配的是“写文件日志”明天换成“发HTTP日志”只要你的目标接口不变客户端代码一行都不用动只是换一个Adapter对象而已。1.3 一个能落地的场景模型日志上报接口为了后面两种实现能够对比我们固定一个场景。你的项目里有一个旧的日志实现类长这样public class FileLogger { public void writeToFile(String level, String message) { // 打开文件、追加日志 System.out.println(文件日志: [ level ] message); } }这个类已经运行了三年内部有各种文件锁、格式处理逻辑不能动。而你的业务层现在希望面向一个更干净的接口比如public interface LogTarget { void log(String level, String message); }为什么不用旧类直接调因为业务层不想知道什么叫“writeToFile”它只关心“log”这个行为。如果以后日志库换成别的实现业务层也不受影响。现在要做的就是写一个适配器让FileLogger这个“已有类”通过LogTarget这个“目标接口”被调用。接下来分别用分类适配器和对象适配器来实现。2. 分类适配器用继承实现把“旧类”直接包装成“新接口”2.1 继承怎么实现适配类Synchronous外层继承旧类并实现新接口分类适配器有的地方也叫类适配器它的实现方式非常直观创建一个新类让它去继承被适配者已有类同时实现目标接口。这样新类天然拥有被适配者的所有公开方法和属性同时又满足目标接口的签名要求。这里的关键在于Java是单继承所以分类适配器只能继承一个类。如果你不需要同时继承多个旧类这种写法就足够干净。它的结构很清晰目标接口定义的是“标准”继承的旧类提供“实现”适配器自己负责把目标接口的方法调用转换成对父类方法的调用。用代码来说就是这样的骨架public class FileLoggerAdapter extends FileLogger implements LogTarget { Override public void log(String level, String message) { // 把新接口的方法转换成父类方法 writeToFile(level, message); } }这里FileLoggerAdapter就是分类适配器。它从父类FileLogger继承了writeToFile又通过implements LogTarget保证了可以被业务层当作LogTarget来使用。业务层眼里它就是一个LogTarget而内部实际干活的是继承自FileLogger的方法。2.2 分类适配器的适用场景与利弊分类适配器有两个非常明显的好处。第一是代码量少如果一个旧类的方法很多你只需要在自己关心的方法上做“重命名”其他不想动的方法可以原样继承不会被强制暴露成一个“多余的中转方法”。第二是它可以覆盖父类的方法如果你对旧类的某个方法不满意在适配器里重写它就行了旧类的源码依然不用动。但坏处也很致命。首先是Java单继承的限制如果你的适配器还想继承其他类就无法实现。其次继承会让适配器和被适配者形成强绑定父类的方法和内部状态全都会暴露给适配器如果父类的构造方法需要参数适配器就必须显式调用super(...)这会让适配器的创建依赖于父类的内部构造。第三继承破坏了封装性父类内部实现细节一旦变化适配器可能无声无息地跟随变化。换个角度说分类适配器其实引入了“一个类同时属于两个类型体系”的交叉容易让人困惑。所以分类适配器比较适合这样的场景被适配者是你完全可控的类你只想给它“换个马甲”目标接口的方法和被适配者的方法数量接近转换逻辑简单你不需要适配多个旧类也不需要保留旧类的原始行为。换句话说它适合“快速给旧类做一个新身份”的场景。2.3 分类适配器实例演示旧日志类转化为新日志接口回到日志场景完整看一下分类适配器的代码。首先是被适配者老文件日志类我们当成“已有类”坚决不改public class FileLogger { public void writeToFile(String level, String message) { String line String.format(%s %s %s%n, java.time.LocalDateTime.now(), level, message); System.out.print(line); // 模拟写文件 } }然后是目标接口public interface LogTarget { void log(String level, String message); }接着是分类适配器public class FileLogAdapter extends FileLogger implements LogTarget { Override public void log(String level, String message) { // 这里可以加一层格式整理 writeToFile(level, message); } }最后是客户端调用public class Client { public static void main(String[] args) { LogTarget logger new FileLogAdapter(); logger.log(INFO, 用户登录成功); } }你发现没有Client里只用LogTarget它甚至不知道FileLogger的存在。如果以后需要换成数据库日志只需要再写一个DbLogAdapter然后把LogTarget logger new DbLogAdapter()即可。这个例子也展示了分类适配器的典型用法——继承FileLogger实现LogTarget通过log方法调用父类的writeToFile。代码虽然简单但它能跑通是因为适配器本身同时满足了两个抽象继承了老类的能力又符合新接口的约束。3. 对象适配器用组合实现把“旧类”作为成员变量注入3.1 组合为什么更灵活持有被适配对象而不是继承它对象适配器是头脑清晰的设计师通常默认的选择它的核心变化在于不继承被适配者而是把被适配者作为一个成员变量放进来。适配器实现目标接口内部持有被适配者对象在接口方法里调用这个被持有对象的方法。术语上把这种关系称为“组合”也就是“有一个”的关系而不是“是一个”的关系。这个转变非常关键。继承意味着你“成为”了那个旧类你必须接受它的所有属性、方法、可见性你被绑死在单一祖先上。组合意味着你“拥有”那个旧类你可以决定什么时候调用它、调用它的哪几个方法、甚至完全不调用它。组合同时解除了单继承的束缚一个适配器可以持有多个被适配对象分别处理它们的转换逻辑。还是拿日志例子来看对象适配器的骨架是这样的public class FileLoggerAdapter implements LogTarget { private final FileLogger fileLogger; public FileLoggerAdapter(FileLogger fileLogger) { this.fileLogger fileLogger; } Override public void log(String level, String message) { fileLogger.writeToFile(level, message); } }可以看到适配器不再继承FileLogger而是在构造时接收一个外部传入的FileLogger实例。业务层创建适配器的时候会先把旧对象构造出来传进来FileLogger fileLogger new FileLogger(); LogTarget logger new FileLoggerAdapter(fileLogger); logger.log(INFO, 用户登录成功);3.2 对象适配器的亮点与代价对象适配器在工程里更受欢迎理由很充分。第一它尊重封装。适配器只通过被适配者的公开方法去调用它不关心它的内部继承树也不强制建立父子关系。第二它非常灵活。你可以为一个被适配者实现多个目标接口也可以反过来让一个适配器持有多个被适配者把它们组合成新的行为。第三它和装饰器模式、代理模式更容易区分因为组合本来就是面向对象设计中比继承更受推崇的关系。当然对象适配器也有自己的代价。最直观的是需要手动多写一个构造方法和成员变量代码量会比分类适配器多一些。另外如果你需要对被适配者的“所有方法”都做一层转换组合模式下你要把每个方法都包一遍继承模式下这些方法会直接暴露反而不需要额外写。再有对象适配器在创建时依赖外部传入被适配者如果被适配者的构造逻辑很复杂创建流程会稍显繁琐。你会发现所谓“代价”其实是设计上的取舍。继承式的快捷是建立在强耦合上的组合式的繁琐换来了松耦合。真正需要为对象适配器多付的成本也就是那几行代码跟它换来的可维护性比起来简直不值一提。3.3 对象适配器实例演示同样的日志需求换种写法为了让对比更直观我们把上一个日志例子用对象适配器重写一遍。被适配者和目标接口保持完全一样不重复贴了直接看适配器public class FileLoggerAdapter implements LogTarget { private final FileLogger fileLogger; public FileLoggerAdapter(FileLogger fileLogger) { this.fileLogger fileLogger; } Override public void log(String level, String message) { // 可以做格式转换比如统一大写 String normalizedLevel level null ? INFO : level.toUpperCase(); fileLogger.writeToFile(normalizedLevel, message); } }客户端使用public class Client { public static void main(String[] args) { FileLogger fileLogger new FileLogger(); LogTarget logger new FileLoggerAdapter(fileLogger); logger.log(info, 用户登录成功); } }注意这里我故意传了小写的info适配器负责把它转成大写这就是一种“适配”——不仅仅是重命名方法还可以处理接口之间的参数语义差异。如果将来要把日志发给外部平台外部平台要求的格式可能完全不同你只要在log方法里改写适配逻辑客户端不用感知。对象适配器还有一个很加分的特点它支持“延迟创建”和“共享复用”。比如你可以在适配器内部持有多个被适配者根据参数决定调用哪一个public class SmartLogAdapter implements LogTarget { private final FileLogger fileLogger; private final HttpLogger httpLogger; public SmartLogAdapter(FileLogger fileLogger, HttpLogger httpLogger) { this.fileLogger fileLogger; this.httpLogger httpLogger; } Override public void log(String level, String message) { if (ERROR.equals(level)) { httpLogger.send(level, message); // 错误日志走网络 } else { fileLogger.writeToFile(level, message); // 普通日志写文件 } } }这种“多被适配者”的能力是分类适配器做不到的因为它只能继承一个父类。4. 分类适配器 vs 对象适配器一图看懂区别与选择标准4.1 关键差异对照表很多初学设计模式的人会陷入一个误区非黑即白地判断哪种适配器更好。其实两者解决的痛点一样只是实现策略不同各有适用土壤。我把关键差异整理成一张表方便你对照对比维度分类适配器继承实现对象适配器组合实现实现方式继承被适配者并实现目标接口持有被适配者实例并实现目标接口关系类型“是一个”的继承关系“有一个”的组合关系与旧类耦合度高父类变化会影响适配器低只依赖公开方法是否需要手动创建被适配者不需要通过super构造需要通过构造传入或内部创建能否适配多个旧类不能Java单继承能可持有多个被适配者能否自动暴露旧类额外方法能子类自动继承不能未包装的方法不暴露能否重写被适配者行为能直接覆盖父类方法能在方法体里决定是否调用旧逻辑代码量较少略多对调用方透明性透明透明推荐程度少用默认推荐这里“推荐程度”我直接写了少用和默认推荐。原因前面也说了继承本身就是一种比组合更脆弱的复用方式。但教材里仍然保留分类适配器是因为它确实在某些限制条件下有存在意义比如你无法修改被适配者的构造方式又希望快速满足一个新接口。4.2 选择指南什么时候用继承式什么时候用组合式选择其实可以量化成一个决策流程。你先问自己三个问题第一个问题我需要适配的“已有类”是不是只有一个如果是多个直接放弃分类适配器因为单继承装不下多个父类。只能选择对象适配器在适配器里同时持有多个旧对象。第二个问题我是否需要“原样复用”被适配者的所有公开方法如果目标接口几乎和被适配者的方法完全一致只是改了类名、方法名那么分类适配器可以少写很多包装代码。但这种情况其实是少数更多时候目标接口是经过抽象精简的只需要用到旧类的一部分能力对象适配器更合适。第三个问题被适配者的构造过程是否复杂如果它的构造需要一堆参数而且这些参数在适配器内部就能准备好那么分类适配器可以通过super(...)来构造。但如果你希望把构建细节留给调用方组合式更自然因为调用方可以先创建被适配者再告诉适配器。我个人的默认选择是除非有非常明确的理由需要继承否则一律用对象适配器。这一条不仅适用于适配器模式几乎适用于所有“两种关系都可以实现”的设计抉择。组合带来的解耦和弹性可以帮你省掉未来大量改代码的时间。5. 实操过程从零实现一个安全的适配器完整步骤5.1 步骤一定义目标接口看清“标准”动手写适配器之前先别急着操作被适配者第一步是把“目标接口”看清楚。这个接口是你业务层希望使用的标准它有可能是你自己定义的也有可能是第三方框架要求的。无论哪种你要把它视为“稳定的协议”。实际操作时我会先打开接口文档把每个方法的入参、返回值、异常声明、语义全都列出来。比如LogTarget.log(String level, String message)这个方法的level到底传什么范围是INFO/ERROR还是任意字符串message要不要做编码这些细节决定了适配器内部是否需要做转换。不要太相信接口注释最好找出至少两三个真实调用案例看看业务方是怎么用这个接口的。这样做的目的是防止你把适配器写成了“把A方法改成B方法”的形式化代码却忽略了语义层面的差异。如果目标接口允许抛异常但被适配者不会抛你的适配器就得决定是吞掉异常还是包装成运行时异常。5.2 步骤二确定被适配者梳理方法映射第二步把要适配的旧类的方法梳理出来。这一步要列出被适配者的所有公开方法以及目标接口的方法然后做一个映射表。映射不是简单的一一对应有些目标接口方法可能不需要用到被适配者直接返回默认值有些目标接口方法可能要用到被适配者多个方法组合。我在做日志适配的时候就整理过一张表目标接口方法被适配者方法转换逻辑log(String level, String message)writeToFile(String level, String message)直接把参数透传level统一转大写flush()flushAndClose()只调一次flushAndClose忽略返回值close()closeWriter()包装为无返回值这张表的价值不只是给自己看更是后期写单元测试的依据。你可以针对表格里的每个映射写一条测试用例确保每个目标接口方法的行为符合预期。5.3 步骤三选择适配策略并编写Adapter到了这一步才考虑用分类还是对象适配器。判断依据就是前面第4节说的决策问题。默认选对象适配器。下面我以对象适配器为例给出一个更完整的实现。假设被适配者还有关闭和刷新方法public class FileLogger { public void writeToFile(String level, String message) { System.out.println(文件日志: [ level ] message); } public void flushAndClose() { // 模拟刷新并关闭 System.out.println(文件日志: 已刷新并关闭); } }目标接口扩展为三个方法public interface LogTarget { void log(String level, String message); void flush(); void close(); }对象适配器实现public class FileLoggerAdapter implements LogTarget { private final FileLogger fileLogger; public FileLoggerAdapter(FileLogger fileLogger) { this.fileLogger fileLogger; } Override public void log(String level, String message) { String normalized level null ? INFO : level.toUpperCase(); fileLogger.writeToFile(normalized, message); } Override public void flush() { // 这里目标接口不想暴露flushAndClose的AndClose语义 // 可以通过重载的方式只刷新比如调用一个只刷新的方法 // 假设FileLogger有flushOnly()这里就调它 } Override public void close() { fileLogger.flushAndClose(); } }这个例子里flush方法的处理有点取巧如果FileLogger没有单独的flushOnly方法适配器需要自己决定语义。这里要强调适配器可以调整方法粒度但不要让适配器私自去猜测旧类的意图。如果旧类没有提供对应能力宁可让适配器调用一个“最接近”的方法并在注释里说清楚也不要为了凑方法签名而瞎写。5.4 步骤四测试兼容性与边界情况适配器写完后测试是最容易被忽略的环节。许多人只测“正常路径”传一个正常参数看到能打印就完事了。这样不够适配器最容易出错的地方恰恰是边界情况。我常用的测试清单包括四类参数为空时怎么处理参数格式非法时是否抛异常异常在被适配者内部抛出时适配器是透传还是包装适配器是否被并发调用目标接口和被适配者的线程安全性是否匹配。拿日志适配器来说level传null时适配器要决定是否给默认值。message传null时被适配者能不能接受如果不能适配器最好主动抛IllegalArgumentException不要让NullPointerException从深层冒出来这样排查起来更痛苦。还有并发场景如果FileLogger不是线程安全的而业务层是并发打日志适配器里应该加锁否则会实际运行中产生日志交错或数据丢失。5.5 实战中容易踩的坑空指针、循环调用、异常吞掉根据我的排查经验适配器模式在实战中有三个高频坑。第一个坑是空指针。构造适配器时忘了传被适配者或者被适配者在某个方法里返回了null而适配器没有判空。我建议在构造函数里就校验如果传入为null直接抛NullPointerException让问题尽早暴露。public FileLoggerAdapter(FileLogger fileLogger) { if (fileLogger null) { throw new IllegalArgumentException(fileLogger must not be null); } this.fileLogger fileLogger; }第二个坑是循环调用。有些适配器为了“同时适配两个方向”会在被适配者的方法里又调用适配器结果形成无限递归。这个在代码复审时尤其要小心。解决方法很简单适配器只做单向转换双向转换拆成两个独立的适配器类。第三个坑是异常吞掉。有些同学为了让调用方“无感”在适配器里写了大大的try-catch然后把异常打印一下就吞掉了。这在业务里埋雷因为调用方如果依赖某个方法的返回值或者异常来感知失败吞掉异常等于静默失败。适配器可以在合适的抽象层做异常包装但不要无条件吞掉。比如把受检异常转换成运行时异常是可以接受的但直接catch (Exception e) {}就要警惕。6. 常见问题与排查技巧实录6.1 为什么适配器里调不到被适配者的私有方法这个问题经常出现在分类适配器里。分类适配器通过继承获得了被适配者的公开和受保护方法但私有方法还是拿不到。这其实是好事因为适配器不应该依赖私有方法。如果你真的需要访问某个私有逻辑可以考虑把这些方法提升为protected或者把该逻辑抽象成一个独立的组件。更推荐的做法是改去组合让适配器通过公开方法访问调用方负责把旧类实例传进来。6.2 适配器和装饰器模式长得像怎么区分两个模式都涉及“把一个对象包起来”的结构但目的完全不同。适配器是为了“转换接口”让原来不兼容的接口可以在一起工作装饰器是为了“增强行为”在保持原接口不变的前提下给对象添加新职责。怎么辨别看目标接口。如果包装后的对象暴露的接口和原来不一样那是适配器如果包装后的对象暴露的接口和原来一样只是加了点功能那是装饰器。比如LogTarget和FileLogger的接口不同所以是适配器如果还是叫FileLogger接口只是给日志加了加密那就是装饰器。6.3 适配器模式会不会影响性能适配器本身多一层方法调用对绝大多数业务系统来说这层调用带来的性能损耗可以忽略不计。真正要注意的是不要在适配器里面做重活。有些同事会把数据转换逻辑放到适配器里比如把消息体从XML转成JSON这个操作本身可能很耗时适配器只是“编排”不是“执行者”。如果你发现适配器耗时高先看是适配器自己做了转换还是调用了被适配者的重逻辑。后者跟你没关系前者你就应该把转换逻辑拆出去。6.4 一个适配器可以同时适配多个旧类吗可以。对象适配器天然支持“多被适配者”你可以在一个适配器里持有两个甚至多个旧类实例。但注意要控制复杂度如果适配器内部逻辑超过两个分支建议拆分。分类适配器做不到多父类所以这种需求下只能选对象适配器。6.5 代码审查时怎么快速判断适配器写得好不好我复审其他人的适配器代码时会看这几点第一是否修改了被适配者源码。如果改了说明这不该叫适配器了应该叫“重构老类”。第二适配器内部是否存在业务规则。如果一段规则写在适配器里且未来可能在多个地方复用这段规则就应该抽出来。第三异常处理是否合理。第四适配器是否承担了它不该承担的职责比如又做接口转换又做日志记录又做性能统计这种“万能适配器”就需要拆。7. 最后的实操心得关于适配器模式我最想说的是别把适配器当成“补丁”的代名词。优秀的适配器是提前规划好的防腐层它保护你的业务代码不依赖外部变化糟糕的适配器则是四处打补丁谁改都往里塞逻辑最后变成一团浆糊。我的习惯是每写一个适配器就给它配一个对应的单元测试测试里写明“被适配者的语义”和“目标接口的语义”之间的映射关系这样以后即使替换被适配者单元测试也能立刻告诉我们哪些语义被破坏了。还有个小技巧想分享当你不得不在“继承”和“组合”之间犹豫时试着把适配器的名字写出来。如果名字里包含“文件”“日志”“HTTP”这种具体实现词说明适配器和被适配者绑得太紧考虑换成组合式让适配器通过构造参数接收实现反而更有弹性。反过来如果只是极少数的临时转换分类适配器能省你三分钟那用也无妨。说到底适配器模式就是一场关于“边界”的修炼。你自己需要想清楚哪里是老代码的边界哪里是新接口的边界而适配器就是那个站在边界的联络员。写它之前多问自己一句这个转接头是真的需要还是我设计上偷懒了想清楚这一点你的代码会比绝大多数教科书示例都要健壮。
