适配器和装饰器模式绝对是 Java 面试里被问烂了、但翻车率也最高的一组设计模式。我当面试官这几年十个候选人里至少有四五个会把这两个搞混——有人能一字不差背出定义一画类图就露馅有人代码写得出来但追问一句“JDK 的 IO 流里哪个是适配器、哪个是装饰器”就卡住。这次我直接把这两个模式彻底掰开揉碎意图、类图、源码、手写代码、面试答题模板全部拉通讲一遍读完你不仅能答对还能答出区分度。不管你是准备校招社招还是想把手头老代码重构一把这套理解框架都直接能用。1. 两个模式各自到底在解决什么问题1.1 适配器的本质接口翻译官适配器想解决的问题特别朴素两个已经存在的东西接口对不上怎么让它们一起工作我常跟人打比方——你从国外带回来一个电器插头是欧标圆脚家里插座是国标扁孔硬插肯定不行于是你买一个转换头。转换头一边接电器一边接插座电气信号还是原来那套但物理接口被它“翻译”成了插座认识的样子。对应到代码里系统里已经有一个MicroUSBDevice方法叫chargeWithMicroUSB()但新模块统一约定用TypeCCharger接口的charge()。你不能改老设备改不动、不该改、或者它是第三方给的也不能改新模块的约定怎么办写一个适配器类它实现新接口TypeCCharger内部持有一个MicroUSBDevicecharge()方法里转发调用chargeWithMicroUSB()。对外调用者只看到 Type-C 充电对内真正充电的还是那台老设备。所以适配器模式的核心词是转换。它不在乎功能变强还是变弱只在乎“让两边能配合”。被适配者往往是你无法修改的代码——老系统、第三方 SDK、历史遗留接口一旦你能直接改通常就不需要这个模式了。这个“我改不了就包一层转接口”的思路是判断适配器的第一把钥匙。1.2 装饰器的本质功能叠加器装饰器解决的是另一类问题功能要怎么动态扩展才能不修改原类、不搞出子类爆炸还是打比方——你去咖啡店点一杯美式18 块。想要加牛奶加 5 块想要加糖加 2 块。美式加奶加糖还是咖啡你不会为“牛奶美式”“糖奶美式”各定义一个新品类而是在基础咖啡上层层叠加配料。每一层配料做的事很简单在我包着的那个东西的描述后面补一句“ 牛奶”价格上加 5 块。代码里也是一样的味道。有一个Coffee接口一个Americano基础实现。现在写一个抽象装饰器CoffeeDecorator它实现Coffee接口同时构造器里接收一个Coffee引用。再加MilkDecorator、SugarDecorator每个装饰器重写方法时都是“先调被包裹对象的方法再补上自己的增强”。调用的时候可以一层套一层Coffee coffee new Americano(); coffee new MilkDecorator(coffee); coffee new SugarDecorator(coffee);最终这杯咖啡名字是“美式 牛奶 糖”价格是 18 5 2。整个过程接口从头到尾都是Coffee调用者感知不到中间加了多少层。功能变强了接口没变——这就是装饰器和适配器最根本的分水岭。1.3 一句话记住核心区别很多八股文背得滚瓜烂熟但一上场就混就是因为没有把“一句话结论”焊死在脑子里。我的总结就一句适配器改变接口目的是兼容装饰器不改变接口目的是增强。再补一张对比表面试前扫一眼就够了对比维度适配器模式装饰器模式核心目的接口转换让不兼容的类协作动态增强职责功能叠加接口有没有变变了从被适配者接口转成目标接口没变一直是组件接口典型结构实现 Target持有 Adaptee实现 Component持有 Component能否多层嵌套通常一层即可嵌套没意义可以无限层叠加组合自由调用者感知只能看到目标接口仍按原接口使用感知不到包装别名无Wrapper包装器生活类比插头转换头、读卡器咖啡加奶加糖、蛋糕裱花这个“接口变没变 目的是什么”的判断框架后面所有内容都是围绕它展开的。先记住再往下看代码和源码你会发现理解会扎实很多。2. 从类图到代码结构差异一目了然2.1 适配器模式的角色拆解适配器模式一共三个核心角色不多不少目标接口Target调用方期望的接口比如刚才的TypeCCharger。被适配者Adaptee已经存在的、接口不匹配的类比如MicroUSBDevice。适配器Adapter核心角色实现 Target同时持有/继承 Adaptee在 Target 的方法里完成转发和转换。适配器有两种实现风格这本身就是一个高频考点。第一种叫类适配器用继承实现public class TypeCAdapter extends MicroUSBDevice implements TypeCCharger { Override public void charge() { chargeWithMicroUSB(); } }第二种叫对象适配器用组合实现也就是前面写过的写法——实现 Target 接口构造器注入 Adaptee 实例。两者对比类适配器在 Java 里受单继承限制而且会把父类的 protected 方法暴露给子类耦合更重对象适配器更灵活被适配者可以替换也不污染接口所以实际项目里几乎都用对象适配器。面试问到就答组合优先于继承这也符合《Effective Java》一贯的主张。还有个容易忽略的细节适配器内部不只是“简单转发”很多时候要做格式转换。比如老接口返回 XML新接口要 JSON适配器在转发的同时要把数据格式转换掉老接口方法参数是String目标接口要Map适配器也要负责拆装。这也是它叫“翻译官”而不是“传声筒”的原因。2.2 装饰器模式的角色拆解装饰器模式有四个角色组件接口Component原始对象和目标装饰器共同实现的接口比如Coffee。具体组件ConcreteComponent真正干活的基础类比如Americano。抽象装饰器Decorator实现 Component持有 Component 引用构造器强制注入。具体装饰器ConcreteDecorator继承抽象装饰器每个类只负责一项增强职责。这里有两个设计关键点面试时值得主动讲出来。第一抽象装饰器为什么要有因为它把“持有被包装对象”这个公共逻辑固定下来了具体装饰器只需专注自己的增强逻辑。没有抽象装饰器也行但每个具体装饰器都要自己写构造器注入代码会重复。第二装饰器为什么能替代继承假设有 3 种咖啡、3 种配料用继承实现“任意搭配”理论上要 3 × 2³ 种组合类直接爆炸。用装饰器你只需要 3 个基础组件类 3 个装饰器类就能组合出所有可能。而且加一种新配料只需新增一个装饰器类完全遵循开闭原则——对扩展开放对修改封闭。这个“组合优于继承”的论证在面试里非常加分。2.3 两份可运行的代码对比光说不练假把式。我把两个模式的完整可运行版本都贴出来建议你自己在本地跑一遍。适配器模式代码// 目标接口新系统统一用 Type-C 充电 public interface TypeCCharger { void charge(); } // 被适配者老设备接口是 MicroUSB public class MicroUSBDevice { public void chargeWithMicroUSB() { System.out.println(MicroUSB 接口正在充电); } } // 适配器把 MicroUSB 包装成 Type-C 接口 public class TypeCAdapter implements TypeCCharger { private final MicroUSBDevice device; public TypeCAdapter(MicroUSBDevice device) { this.device device; } Override public void charge() { device.chargeWithMicroUSB(); } }调用方视角MicroUSBDevice oldDevice new MicroUSBDevice(); TypeCCharger charger new TypeCAdapter(oldDevice); charger.charge(); // 外部看起来就是在用 Type-C 充电装饰器模式代码// 组件接口 public interface Coffee { String name(); double price(); } // 具体组件基础美式 public class Americano implements Coffee { Override public String name() { return 美式咖啡; } Override public double price() { return 18.0; } } // 抽象装饰器接口不变 构造器注入 public abstract class CoffeeDecorator implements Coffee { protected final Coffee coffee; public CoffeeDecorator(Coffee coffee) { this.coffee coffee; } } // 具体装饰器加牛奶 public class MilkDecorator extends CoffeeDecorator { public MilkDecorator(Coffee coffee) { super(coffee); } Override public String name() { return coffee.name() 牛奶; } Override public double price() { return coffee.price() 5.0; } } // 具体装饰器加糖 public class SugarDecorator extends CoffeeDecorator { public SugarDecorator(Coffee coffee) { super(coffee); } Override public String name() { return coffee.name() 糖; } Override public double price() { return coffee.price() 2.0; } }调用方视角Coffee coffee new Americano(); coffee new MilkDecorator(coffee); coffee new SugarDecorator(coffee); System.out.println(coffee.name() 价格 coffee.price()); // 输出美式咖啡 牛奶 糖价格25.0注意两段代码的区别适配器里调用方手上的变量类型是新接口TypeCCharger老设备的chargeWithMicroUSB()被完全藏起来了装饰器里变量类型从头到尾都是Coffee加多少层调用代码都不用改。这一实一虚就是两个模式最直观的差异。3. 源码里的真实案例背下来比背定义有用3.1 JDK 里的适配器阵营面试官最爱问“JDK 里有没有现成的例子”你答得出来说明不是只看过概念。我先列适配器阵营。最经典的当属InputStreamReader。它把字节流InputStream转换成字符流Reader完美符合“接口变了”的定义——从读字节变成读字符。用法是Reader reader new InputStreamReader(new FileInputStream(a.txt));FileInputStream是已有的字节流Reader是目标接口InputStreamReader就是中间的转换层。与之配套的OutputStreamWriter同理把字节输出流转成字符输出流。另一个容易被忽视的是Arrays.asList(T... a)。它把数组包装成List这在日常代码里出现频率极高。数组和 List 两套接口不兼容这个方法干的活就是“适配”返回一个实现了 List 接口、但底层由数组支撑的Arrays$ArrayList。注意这个适配出来的 List 不支持add/remove因为数组长度固定——适配器只保证接口能对上不保证功能完全等价这一点也正好呼应了适配器的定义。框架层面Spring MVC 的HandlerAdapter也是典型。DispatcherServlet在doDispatch里拿到一个Handler但Handler可能是Controller方法、HttpRequestHandler、Servlet等多种形态调用方式各不相同。HandlerAdapter把这些不同形态统一成handle()一个入口让前端控制器只依赖一套接口。这就是适配器在大型框架里的标准用法。还有 slf4j 的绑定原理。slf4j 定义了一套统一日志 APIlogback、log4j2 各自实现自己的接口中间靠StaticLoggerBinder这类适配机制完成绑定。你项目里写的是 slf4j API底层却是 logback 的实现这种“接口转换、底层委派”的结构本质上也是适配思想。3.2 JDK 里的装饰器阵营装饰器阵营同样一抓一大把最典型的就是 IO 流家族。BufferedInputStream包装任意InputStream给它加上缓冲能力。它的构造器就是BufferedInputStream(InputStream in)返回的仍然是InputStream。接口没变能力变了这不是装饰器是什么同理BufferedReader给Reader加缓冲还额外提供了readLine()这个便捷增强方法。组合起来就是经典的一行BufferedReader br new BufferedReader(new InputStreamReader(new FileInputStream(a.txt)));这句代码里两个模式都有InputStreamReader是适配器字节流转字符流BufferedReader是装饰器字符流加缓冲。面试时能把这句话拆明白哪个是适配、哪个是装饰、为什么一下就拉出差距了。集合框架里也有。Collections.synchronizedList(list)给一个不是线程安全的ArrayList包上一层同步逻辑返回的仍然是List接口Collections.unmodifiableList(list)给列表加只读保护同样是List接口。这俩都是“接口不变、职责增强”的装饰器思维而且包了多少层调用方完全无感。Servlet 规范里的HttpServletRequestWrapper也是教科书级的装饰器。Spring 系项目里想改请求参数、加自定义 Header常见做法就是写一个类继承HttpServletRequestWrapper重写getHeader()等方法把原来的request传进构造器。它保持HttpServletRequest接口不变在这个基础上叠加自定义行为非常典型。3.3 面试官想听到的源码分析源码例子背下来还不够你要能说出“为什么是 / 为什么不是”的判据。我面试时最反感的就是候选人报菜名说BufferedInputStream是装饰器问他InputStreamReader是什么他说也是装饰器——这就错了。InputStreamReader确实持有一个InputStream结构上看起来像装饰器但你要看清它的意图InputStream读的是字节Reader读的是字符接口类型变了。它要做的是把“字节语义”翻译成“字符语义”比如处理字符集编码这是典型的适配。而BufferedInputStream包的还是InputStream不需要翻译语义只额外提供缓冲数组接口类型没变所以是装饰器。所以我的判断顺序是先看接口变没变再看是转换还是增强。结构相似只是表象意图才是本质。能在源码例子里讲出这个判断逻辑面试官基本就能确定你是真懂而不是背的。4. 高频混淆点与快速判断口诀4.1 最容易踩的三个坑我自己刚学设计模式时也踩过不少坑总结了三个基本涵盖了面试翻车的重灾区。第一个坑把所有“套了一层”的都叫装饰器。很多人看到“一个类持有另一个类、方法里转调”就喊装饰器这是最大的误解。持有 转发只是组合的壳适配器、代理、门面模式都是这个壳。必须先问一句接口变了吗变了就是适配器没变再往下问是控制访问还是增强功能是控制访问就是代理。光看结构永远分不清。第二个坑忽略模式的目的只看代码长相。比如有人非要说InputStreamReader是装饰器因为它也是“包了一个流”。这就是把结构当成了定义。目的才是分水岭适配器是让不兼容的接口能对话装饰器是给同一个接口叠加能力。脱离了意图谈模式跟背死书没区别。第三个坑分不清装饰器和代理模式。两者结构几乎一样都有一个类持有真实对象都实现了共同接口代理也可以不实现共同接口但常见实现方式是实现。区别在语义代理控制对真实对象的访问——权限校验、延迟加载、远程调用它可能不增加真实对象的功能甚至可能拒绝访问装饰器增强真实对象的功能——加缓冲、加日志、加缓存调用一定落在真实对象上而且结果比原来更强。另外代理的对象通常是被保护者装饰器的对象是被增强者方向完全不同。4.2 三秒判断法面试现场时间紧我给你一套“三秒判断法”照着走基本不会错接口变了吗变了 → 适配器。比如字节流变字符流、数组变 List、MicroUSB 变 Type-C。接口没变那功能增强了吗增强了 → 装饰器。比如加缓冲、加同步、加只读保护、加日志。接口没变但目的是限制访问那是代理模式不是装饰器。再浓缩成一句话适配器换接口装饰器加功能代理管访问。判断问题结论接口变了做的是转换/翻译适配器接口没变做的是增强/叠加装饰器接口没变做的是控制/限制访问代理模式接口没变做的是简化复杂子系统门面模式外观模式4.3 和动态代理联动理解Java 面试里这几个概念经常连环轰炸刚问完装饰器转眼就问 JDK 动态代理。正好借此把边界讲清楚。动态代理基于InvocationHandler和Proxy.newProxyInstance()生成的代理对象是在运行时构建的通过InvocationHandler.invoke()统一拦截方法调用。它的典型用途是 AOP在方法调用前后插日志、做事务、做权限。这个结构上也是“持有目标对象 转发调用”但目的不是给对象加“功能”而是给对象加“控制逻辑”所以它是代理模式不是装饰器。那 AOP 到底算不算装饰器严格讲AOP 的拦截增强更像是装饰器思想的运行时版本——如果你在一个接口方法前后加了缓存逻辑、事务逻辑确实是在增强但实现机制是动态代理。所以我在项目里跟同事讨论时经常说“这是装饰思想的代理实现”。面试这么答说明你不仅知道模式还知道模式之间的演化关系。5. 面试答题模板与追问演练5.1 一分钟标准答案面试时间紧别从设计模式定义开始背。我给你一套结构化答案照着说一分钟讲完信息密度到位“适配器模式和装饰器模式结构上都像包一层但意图相反。适配器解决接口不兼容问题老接口是 MicroUSB而新系统只认 Type-C我写一个适配器类实现 Type-C 接口、内部持有 MicroUSB 对象把充电方法转发翻译过去。核心是接口转换调用者看到的是一个新接口。装饰器解决功能扩展问题接口不变通过一层层包装动态叠加职责比如美式咖啡外面包牛奶、再包糖每次包装返回的还是 Coffee 接口调用者无感知功能却变强了。JDK 里区别也很明显InputStreamReader 把字节流转成字符流接口变了是适配器BufferedInputStream 包住流加缓冲接口没变是装饰器。一句话总结就是适配器改接口装饰器不改接口。”这套答案好在哪里第一有类比面试官好理解第二有结构把两个模式的关键角色讲清楚了第三有源码佐证证明你不是背的第四有总结句收得干净。照着这个骨架你可以换成自己熟悉的例子。5.2 五连问怎么接面试官听完大概率会追加追问我列五个最高频的附上答题要点。追问一类适配器和对象适配器有什么区别答类适配器用继承对象适配器用组合。Java 单继承下类适配器只能适配一个被适配者而且会继承父类的方法和属性耦合较高对象适配器通过组合持有被适配者更灵活可以替换被适配实例推荐使用。类适配器偶尔用在“被适配者方法少、想快速实现”的场景实际项目里几乎都是对象适配器。追问二装饰器用起来很啰嗦为什么不用继承答继承会导致组合爆炸。假设 3 种基础咖啡、3 种配料用继承实现任意搭配可能产生几十个类而且一旦加一种配料又要加一批子类违背开闭原则。装饰器把每个职责拆成独立类自由组合新增配料只需新增一个装饰器类。典型代价是类数量多、嵌套深所以 Java 8 之后函数式接口 lambda 在某些场景可以简化类似的管道处理但装饰器的组合语义依然清晰。追问三IO 流里怎么区分适配器和装饰器答一行代码拆开讲——new BufferedReader(new InputStreamReader(new FileInputStream(a.txt)))。FileInputStream是字节流InputStreamReader把它转换成字符流接口变了是适配器BufferedReader在字符流基础上加缓冲和readLine()接口还是Reader是装饰器。适配完成后再装饰这是 IO 流最经典的分工。追问四适配器和代理模式有什么区别答适配器是为了让不兼容的接口能协作重点在接口转换调用者感知到的是新接口代理模式重点在控制访问权限校验、延迟加载、远程调用代理不一定增强原功能甚至可能不调用原方法。结构上相似但语义完全不同。追问五手写一个装饰器要求体现叠加。答直接写 Coffee 那一套。注意四点装饰器实现和组件相同的接口构造器注入组件增强逻辑写在重写方法里先调原对象方法再补充两个具体装饰器可以任意嵌套。5.3 手写代码的得分要点手写题是面试最直接的考察方式。我面过不少候选人代码风格好的基本都符合下面几条字段类型用接口不用具体类。CoffeeDecorator里持有的是Coffee不是Americano否则就只能装饰特定组件。抽象装饰器要存在。虽然说没有它也能实现但面试官看到抽象装饰器会认为你理解“公共逻辑抽出来”的价值。重写方法时先调被包装对象再做增强。这是装饰器的灵魂不破坏原行为只叠加新行为。顺序反了语义就错了。体现可嵌套性。装饰器互相不知道对方存在一个装饰器只和它包着的那个组件打交道。写代码时不要让MilkDecorator去判断自己外面是不是还有SugarDecorator。命名规范。装饰器类名常用XxxDecorator或XxxWrapper适配器常用XxxAdapter。规范命名本身就是一种可读性和工程素养的体现。手写题还有一个隐性加分项边写边讲解把关键决策说给面试官听。比如写上protected final Coffee coffee时可以顺嘴说一句final保证引用不会被篡改这比你闷头写完再等面试官提问要主动得多。6. 真实项目里的选型经验6.1 什么场景该用适配器项目里的适配器场景远比面试题更实在。我总结成三类。第一类对接第三方接口。公司要接入多个支付渠道每个渠道的 SDK 接口都不一样有的pay(Map)有的doPayment(String, BigDecimal)有的还要先init()。你不可能让业务代码跟着每个 SDK 走于是定一个自己的PaymentService.pay(Order)接口为每个渠道写一个适配器把 SDK 的奇形怪状翻译成统一接口后续业务只认你自己的接口。这就是最典型的适配器应用。第二类老系统改造。手上有一套跑了好几年的老服务返回 XML新消费方全部要求 JSON。直接改老服务风险大、成本高写一个适配层对外暴露 JSON 接口内部调用老服务并把 XML 转成 JSON老系统一行没动两套系统就接上了。我参与过的数据迁移项目里这类适配层经常是过渡期的救命稻草。第三类统一异构数据源。系统里有 MySQL、Redis、ES各自查询方式完全不同。可以定义一个DataRepository.query(key)然后为每个数据源写适配器让上层代码不用关心数据到底存在哪。这样切换存储方案时改动被限制在适配器内部。选适配器的判断标准很简单接口不一致且有一方改不了。能改就直接改接口改不了才适配。6.2 什么场景该用装饰器装饰器的场景核心是“在不破坏原有类的前提下动态扩展职责”。我项目里用得最多的是给基础服务叠加横切能力。比如一个电商的库存服务StockService.deduct()上线后发现需要做三件事操作日志、性能监控、失败重试。直接改原类代码会越来越臃肿而且这些能力别的服务也要用。写三个装饰器LoggingStockDecorator、MetricsStockDecorator、RetryStockDecorator按需组合。将来不要日志了去掉一层包装即可原服务类代码零污染。IO 场景不用多说BufferedInputStream包FileInputStream是天天在用的。集合安全场景也是Collections.synchronizedList包一个普通 List 就能在并发环境里用。这些都属于“同类接口 附加职责”的模式。装饰器替继承的最佳场景是功能可以自由组合、组合数量庞大。如果是单一固定扩展继承几个子类也能接受一旦出现“2 个基础乘 3 个扩展”的矩阵需求立刻转装饰器。6.3 我的一点个人体会做面试官时我判断一个候选人懂不懂设计模式不看定义背得多熟只看两件事第一能不能在 JDK 或项目里指认出真实的模式实例第二能不能讲清楚模式的适用边界。能把适配器、装饰器、代理三者边界讲明白的候选人通常代码里也更少出现“为了用模式而用模式”的烂设计。我自己当年准备面试用的方法是“源码对照 手写三遍 讲给别人听”。先看 Java 源码里的真实用法再不看资料手写一遍最后用自己的话跟同事讲一遍卡住的地方就是理解薄弱处。这套循环来三轮基本就不可能再混这两个模式。最后再分享一个实用经验面试答题时永远先说结论再补例子。一句“适配器改接口装饰器不改接口”亮出判断框架然后用 IO 流或者咖啡的例子展开最后落一句“所以我在 xx 项目里的 xx 场景用过”。这种答法既展示了你对模式的本质理解又展示了工程落地能力比干巴巴背定义分数高出一大截。