本文目录如下1. 为什么需要装饰器模式1.1 装饰器模式解决的核心痛点1.2 典型使用场景1.3 不适合装饰器模式的场景2. 装饰器模式核心体系与角色2.1 核心特点2.2 四大标准角色3. 装饰器模式标准实战实现基础版3.1 业务场景3.2 抽象组件统一消息接口3.3 具体组件原始基础实现核心不变3.4 抽象装饰器统一包装父类3.5 具体装饰器日志增强、加密增强3.6 客户端测试自由叠加、多层装饰3.7 核心代码分析4. 装饰器模式优缺点4.1 优点4.2 缺点5. 工程常见痛点与解决方案5.1 装饰器类过多、类文件泛滥5.2 多层嵌套顺序混乱导致BUG5.3 装饰器重复包装、空包装冗余5.4 接口频繁变更导致维护成本高6. 高频面试易混模式核心区分6.1 装饰器模式 vs 静态继承6.2 装饰器模式 vs 代理模式面试最高频6.3 装饰器模式 vs 适配器模式7. 装饰器模式主流框架落地面试高频7.1 JDK IO 经典落地教科书级7.2 Spring框架落地7.3 Java 集合体系落地8. 核心总结1. 为什么需要装饰器模式装饰器模式是结构型设计模式。核心目标在不修改原有对象、不使用子类继承的前提下动态、透明地给原有对象叠加额外功能。核心设计思想组合优于继承、层层包装、功能叠加、原有代码零侵入。它解决了继承拓展臃肿、静态固化、无法动态叠加功能的核心问题是替代继承做功能增强的最优工程方案。换句话讲当需要对原有类新增额外功能、拓展能力但不想改源码、不想泛滥子类、希望功能可自由组合叠加时使用装饰器模式。1.1 装饰器模式解决的核心痛点a. 继承拓展导致子类爆炸一个基础类有多种拓展能力通过继承组合会产生大量冗余子类维护成本极高。b. 功能拓展静态固化、无法动态组合继承在编译期绑定能力运行时无法灵活增减、自由搭配功能。c. 修改原有源码违反开闭原则直接改原有业务类新增功能会侵入核心逻辑增加线上风险。d. 功能耦合严重、复用性差增强逻辑写死在业务类或子类中无法独立复用、自由拆解。e. 多层拓展代码臃肿混乱多段增强逻辑堆砌在同一个方法内职责混乱、可读性极差。1.2 典型使用场景a. 需要动态叠加、自由组合功能的场景权限校验、日志记录、加密、缓存、重试、限流等可插拔增强能力。b. 原有类功能稳定、禁止修改源码的场景核心基础类稳定需要外围拓展能力零侵入增强。c. 多维度、多层级拓展能力场景IO流读写、报文解析、多层数据包装、多层加工处理。d. 替代继承做功能拓展的场景避免子类泛滥用组合包装替代静态继承。e. 运行时动态增减功能的场景根据业务策略、环境参数动态开启/关闭增强逻辑。1.3 不适合装饰器模式的场景a. 功能拓展固定、无需动态组合能力永久固定、无需叠加切换没必要多层包装。b. 原有对象结构频繁改动基础组件接口频繁变更会导致所有装饰器同步改代码。c. 仅单次简单拓展、无复用需求单次增强直接封装工具类即可过度包装属于过度设计。d. 需要大幅篡改原有核心逻辑装饰器仅做增强拓展不适合替换原有核心行为。2. 装饰器模式核心体系与角色2.1 核心特点1.透明性装饰器与原始组件实现同一接口对外行为完全一致客户端无感知2.可叠加多个装饰器可以层层嵌套、自由组合实现多层能力增强3.零侵入不修改原有基础类代码完全符合开闭原则4.组合替代继承通过对象组合包装替代臃肿的继承层级。2.2 四大标准角色抽象组件Component统一抽象接口定义原始对象和所有装饰器的统一行为规范。具体组件Concrete Component原始基础对象核心业务实现被装饰的主体功能稳定不变。抽象装饰器Decorator持有抽象组件引用实现统一接口是所有具体装饰器的父类负责统一包装。具体装饰器Concrete Decorator继承抽象装饰器叠加具体增强功能实现多层拓展能力。3. 装饰器模式标准实战实现基础版3.1 业务场景基础消息发送功能需要动态叠加日志打印、消息加密能力支持自由组合、多层叠加。3.2 抽象组件统一消息接口// 抽象组件统一行为规范 public interface MessageService { // 统一发送消息方法 void send(String content); }3.3 具体组件原始基础实现核心不变// 具体组件原始基础消息发送功能 public class BaseMessageService implements MessageService { Override public void send(String content) { System.out.println(发送原始消息 content); } }3.4 抽象装饰器统一包装父类// 抽象装饰器所有装饰器父类 public abstract class MessageDecorator implements MessageService { // 持有原始组件/装饰器引用支持层层包装 protected MessageService messageService; public MessageDecorator(MessageService messageService) { this.messageService messageService; } Override public void send(String content) { messageService.send(content); } }3.5 具体装饰器日志增强、加密增强// 具体装饰器日志装饰器 public class LogMessageDecorator extends MessageDecorator { public LogMessageDecorator(MessageService messageService) { super(messageService); } Override public void send(String content) { // 前置增强打印日志 System.out.println(【日志装饰】记录消息发送日志内容 content); // 执行原有核心逻辑 super.send(content); } } // 具体装饰器加密装饰器 public class EncryptMessageDecorator extends MessageDecorator { public EncryptMessageDecorator(MessageService messageService) { super(messageService); } Override public void send(String content) { // 前置增强模拟加密 String encryptContent 加密处理 content; // 执行原有逻辑 super.send(encryptContent); } }3.6 客户端测试自由叠加、多层装饰public class DecoratorClient { public static void main(String[] args) { // 1. 原生基础能力 MessageService base new BaseMessageService(); base.send(普通业务消息); System.out.println(----------); // 2. 单层装饰仅日志 MessageService logService new LogMessageDecorator(new BaseMessageService()); logService.send(日志增强消息); System.out.println(----------); // 3. 多层叠加加密日志 自由组合 MessageService fullService new LogMessageDecorator(new EncryptMessageDecorator(new BaseMessageService())); fullService.send(多层增强业务消息); } }3.7 核心代码分析1. 原始类BaseMessageService完全无改动符合开闭原则2. 装饰器实现同一接口客户端完全无感知透明增强3. 支持任意多层嵌套、任意顺序组合动态拓展能力4. 每个装饰器单一职责只负责自己的增强逻辑可独立复用。4. 装饰器模式优缺点4.1 优点1. 完美符合开闭原则新增增强能力只需新增装饰器不改动原有核心代码。2. 彻底解决子类爆炸问题用组合替代继承无需为每种能力组合创建子类。3. 功能灵活可叠加、可自由组合运行时动态嵌套包装按需开启多层增强。4. 职责单一、解耦彻底每个装饰器只负责一项增强能力代码清晰、易维护、易测试。5. 透明增强、客户端无感知装饰器与原对象接口一致无缝替换。4.2 缺点1. 产生大量装饰器包装类每一种增强都需要一个装饰器类类数量增多。2. 多层嵌套阅读成本高多层包装叠加后调用链路长排查问题需要逐层拆解。3. 顺序依赖问题部分增强逻辑有先后顺序嵌套顺序错误会导致业务异常。4. 接口变动影响所有装饰器当顶层组件接口发生修改时所有依赖该接口的装饰器都需要同步进行适配更新。5. 工程常见痛点与解决方案5.1 装饰器类过多、类文件泛滥问题增强能力过多每个能力单独建类项目结构臃肿。解决方案将轻量增强能力通过静态内部类、统一聚合装饰器收拢减少类文件数量。5.2 多层嵌套顺序混乱导致BUG问题加密、日志、校验、重试等有执行顺序手动嵌套容易写反。解决方案提供装饰器工具构建链统一封装顺序客户端链式调用无需关心层级。5.3 装饰器重复包装、空包装冗余问题重复叠加相同装饰器导致逻辑重复执行。解决方案增加包装标记、容器去重控制每种装饰器仅叠加一次。5.4 接口频繁变更导致维护成本高解决方案顶层组件接口尽量稳定将高频变动的拓展逻辑下沉至装饰器保证核心接口不动。6. 高频面试易混模式核心区分6.1 装饰器模式 vs 静态继承继承编译期静态绑定能力固定、无法动态叠加、子类泛滥、耦合极高。装饰器运行时动态组合能力自由叠加、单一职责、低耦合、符合开闭。6.2 装饰器模式 vs 代理模式面试最高频装饰器模式侧重功能增强、能力叠加透明拓展原有功能核心是「加能力」可以多层嵌套。代理模式侧重访问控制、资源管控控制对象的访问、创建、销毁核心是「管对象」一般单层代理。6.3 装饰器模式 vs 适配器模式装饰器接口不变增强原有能力属于同体系拓展。适配器接口不统一转换接口适配兼容属于跨体系适配。7. 装饰器模式主流框架落地面试高频7.1 JDK IO 经典落地教科书级InputStream为抽象组件FileInputStream为原始具体组件BufferedInputStream、DataInputStream是具体装饰器。底层完全遵循装饰器思想原始文件流 缓存装饰 数据解析装饰可自由组合叠加能力。7.2 Spring框架落地Spring Bean包装拓展BeanWrapper、DecoratingClassLoader均采用装饰器思想对原生对象做包装增强。Spring MVC请求包装HttpServletRequestWrapper、HttpServletResponseWrapper装饰原生请求响应对象实现请求参数修改、包装、增强。7.3 Java 集合体系落地Collections.synchronizedList、unmodifiableList是典型装饰器实现对原生List集合做线程安全、只读能力装饰增强不修改原集合源码。8. 核心总结装饰器模式的核心本质组合替代继承、动态叠加功能、透明增强、零侵入拓展是结构型模式中最适合做可插拔功能增强的核心模式。工程落地选型规范1.需要动态叠加、多维度拓展优先用装饰器彻底杜绝子类爆炸2. 功能增强、日志、加密、缓存、限流等通用能力统一封装为装饰器解耦业务3. 严格遵循单一职责一个装饰器只做一种增强保证可复用、可拆解4. 区分代理、适配器模式不混用、不滥用避免过度设计。装饰器模式是 IO 体系、Spring 底层、日常业务增强的核心基石掌握其「层层包装、动态叠加」的思想是读懂源码、写出高拓展代码的关键。
