## 01、痛点

老李几年前写过第一版订单通知服务，只需要发短信。后来需求增加邮件、企业微信、钉钉、站内信。然后又要求发送前记录日志、过滤敏感词、对内容加密。如果用继承实现，子类会爆炸：

MessageSender
├── SmsSender
├── EmailSender
├── WeComSender
├── SmsLogSender
├── SmsFilterSender
├── SmsEncryptSender
├── SmsLogFilterSender
├── SmsLogEncryptSender
└── ...

每增加一个能力，类数量成倍增加。不同渠道逻辑互相复制，日志、过滤、加密散落各处。一个小需求要改五六个类，新人不敢动。

> 锐评：如果只有两个能力，继承还能糊住；当能力和渠道继续叠加，类名会先撑爆代码库。

设计模式真正解决的，不是代码写得不高级，而是变化开始失控。

## 02、是什么

装饰器模式解决“对象能力需要动态叠加”的问题。核心思想是：用组合代替继承，把增强逻辑包在原有对象外层。

四个角色：
- Component：抽象组件，定义统一能力。
- ConcreteComponent：具体组件，提供基础能力。
- Decorator：装饰器抽象，持有一个Component引用，并实现Component接口。
- ConcreteDecorator：具体装饰器，在调用前后增加职责。

结构如下：

Client
↓
MessageSender (Component)
├── SmsMessageSender (ConcreteComponent)
└── MessageSenderDecorator (Decorator)
    ├── LoggingDecorator
    ├── SensitiveWordFilterDecorator
    └── EncryptDecorator

Java IO是典型应用：InputStream是Component，FileInputStream是ConcreteComponent，FilterInputStream是Decorator，BufferedInputStream是ConcreteDecorator。

## 03、为什么

很多开发者学过装饰器，但不会在真实项目中使用。常见误区：

误区一：先记模式，再找地方套。
误区二：把所有包装都叫装饰器。
误区三：嵌套越深，架构越高级。

判断是否该用装饰器，可以问自己：
1. 变化是否真实存在？
2. 增强能力是否独立且可组合？
3. 修改是否频繁影响原类？
4. 引入模式后，理解成本是否低于原来的维护成本？

公式：模式收益 = 未来变化成本降低 / 当前抽象复杂度增加。

> 锐评：十行代码解决的问题，不要嵌套五层装饰器。装饰器不是让你的对象看起来高级，而是让组合关系更清晰。

## 04、架构

按照开发问题分类，设计模式不是23个名字，而是变化的地图：
- 对象怎么创建？→ 工厂 / 建造者
- 多个实现怎么切换？→ 策略
- 流程怎么复用？→ 模板方法
- 多个节点怎么串起来？→ 责任链
- 外部系统怎么接进来？→ 适配器
- 功能怎么动态叠加？→ 装饰器
- 状态不同怎么改变行为？→ 状态模式

识别路径：
需求变化 → 变化点识别 → 职责拆分 → 模式选择 → 接口稳定 → 实现扩展

装饰器适用于横切能力叠加，例如日志、过滤、加密、缓存、性能监控。

## 05、实战

### 5.1 业务场景

统一消息发送接口，支持短信、邮件，并且能够自由叠加日志、敏感词过滤、加密。先看第一版代码。

接口：
public interface MessageSender {
    void send(String content);
}

基础实现：
public class SmsMessageSender implements MessageSender {
    public void send(String content) {
        // 发送短信
    }
}

需求增加日志时，直接改send方法；增加过滤、加密后，SmsMessageSender里if/else越来越多。其他渠道复制同样逻辑，三个渠道各有三种能力，就要维护九个类。

### 5.2 模式重构

抽象装饰器：
public abstract class MessageSenderDecorator implements MessageSender {
    protected MessageSender delegate;
    public MessageSenderDecorator(MessageSender delegate) {
        this.delegate = delegate;
    }
    public void send(String content) {
        delegate.send(content);
    }
}

日志装饰器：
public class LoggingDecorator extends MessageSenderDecorator {
    public LoggingDecorator(MessageSender delegate) { super(delegate); }
    public void send(String content) {
        // 记录发送前日志
        delegate.send(content);
        // 记录发送后日志
    }
}

敏感词过滤装饰器：
public class SensitiveWordFilterDecorator extends MessageSenderDecorator {
    public void send(String content) {
        String filtered = filterService.filter(content);
        delegate.send(filtered);
    }
}

加密装饰器：
public class EncryptDecorator extends MessageSenderDecorator {
    public void send(String content) {
        String encrypted = encryptService.encrypt(content);
        delegate.send(encrypted);
    }
}

组合使用：
MessageSender sender = new EncryptDecorator(
    new SensitiveWordFilterDecorator(
        new LoggingDecorator(
            new SmsMessageSender()
        )
    )
);
sender.send(content);

在Spring中可以通过@Bean手动组合：
@Configuration
public class SenderConfig {
    @Bean
    public MessageSender messageSender() {
        return new EncryptDecorator(
            new SensitiveWordFilterDecorator(
                new LoggingDecorator(
                    new SmsMessageSender()
                )
            )
        );
    }
}

调用链字符图：
Client
↓
EncryptDecorator
↓
SensitiveWordFilterDecorator
↓
LoggingDecorator
↓
SmsMessageSender

可以自由调整顺序，例如先过滤再加密，或先加密再日志。

### 5.3 收益

新增能力无需修改原类；多个装饰器自由组合；每个装饰器职责单一；方便单元测试。

### 5.4 代价

类数量增加；调用链变长，调试栈更深；嵌套顺序必须清晰；如果增强之间有强依赖，组合容易出错。

### 5.5 什么时候不要用

只有一次增强且未来不会变化，直接在原方法加代码更直接。增强顺序固定且业务耦合强，可以考虑模板方法或管道。增强严重影响业务语义时，不要硬包装。

> 锐评：不是所有包装都叫装饰器。包装了一个类就宣称用了设计模式，和给变量改名叫strategy一样幼稚。

### 5.6 与Proxy差异

装饰器侧重“增强能力”，通常在构造时传入被装饰对象；代理侧重“控制访问”，被代理对象可以懒加载，代理可以隐藏真实对象。Spring AOP代理用于事务、权限控制，而不是叠加业务能力。装饰器关注“加功能”，代理关注“管访问”。

## 06、洞见

装饰器模式背后是“组合优于继承”。好的抽象来自重复出现的变化，而不是提前想象。Java IO、Spring中的HttpServletRequestWrapper、Collections.synchronizedList都是装饰器思想。Spring框架本身就是设计模式的大型实践。

> 锐评：为了可扩展而提前造出五个装饰器，结果只用了基础实现，这不是设计，是行为艺术。

初级开发者喜欢把代码写出来，高级开发者开始考虑怎么组合，架构师最终考虑的是哪些地方根本不值得装饰。

## 07、行动

第一阶段：认识5个最常用模式：策略、工厂、模板方法、责任链、装饰器。

第二阶段：从自己的项目里找坏味道：继承树变深、重复包装、发送前后逻辑散落。

第三阶段：尝试重构。每次重构回答五个问题：
1. 变化点是什么？
2. 不使用模式会怎样？
3. 使用模式增加了什么复杂度？
4. 下一次新增需求，需要修改几个地方？
5. 新人是否更容易理解？

七天实践计划：
Day 1：找一个继承爆炸或重复包装的类。
Day 2：识别可叠加的独立能力。
Day 3：抽象出Decorator。
Day 4：实现日志装饰器。
Day 5：增加过滤和加密装饰器。
Day 6：自由组合“过滤 → 加密 → 日志 → 发送”链。
Day 7：重新评估哪些装饰器其实多余。

## 08、小结

金句：装饰器模式不是让对象变多，而是让组合变清晰。

设计模式不是为了让代码看起来高级，而是为了让下一次需求变化时，你不用推倒重来。真正值得学习的不是23个名字，而是看到变化、识别变化、隔离变化的能力。如果读完这篇文章，你少写了一个继承爆炸的类，这篇文章就算没有白写。

## 09、链接与概念说明

GoF是Erich Gamma等四人所著《Design Patterns》中提出的23种设计模式。装饰器属于结构型模式，主要解决对象职责动态扩展问题。SOLID原则中的开闭原则与装饰器紧密相关：对扩展开放，对修改关闭。推荐阅读：《Head First设计模式》、Effective Java第18条“组合优于继承”、Java官方文档java.io包。文中未提供外部链接，避免虚构。

老李几年前写过第一版订单通知服务，只需要发短信。后来需求增加邮件、企业微信、钉钉、站内信。然后又要求发送前记录日志、过滤敏感词、对内容加密。如果用继承实现，子类会爆炸：

《设计模式军体拳第7招》 装饰器模式 Decorator——动态叠加对象能力

消息发送从基础能力到日志、过滤、加密，继承写法导致类爆炸。本文用Java/Spring重构，详解装饰器四角色、组合叠加、Java IO与Proxy差异，给出不用

架构师

编程语言

架构设计

后端

装饰器模式通过组合代替继承，实现消息发送功能（短信、邮件）的动态增强（日志、过滤、加密），解决类爆炸问题，提升扩展性与维护性，降低多能力叠加的复杂度。

单元测试

短信

Java

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第7招》 装饰器模式 Decorator——动态叠加对象能力-腾讯云开发者社区-腾讯云

《设计模式军体拳第7招》装饰器模式 Decorator——动态叠加对象能力

《设计模式军体拳第7招》装饰器模式 Decorator——动态叠加对象能力

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第7招》 装饰器模式 Decorator——动态叠加对象能力

《设计模式军体拳第7招》 装饰器模式 Decorator——动态叠加对象能力

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第7招》装饰器模式 Decorator——动态叠加对象能力

《设计模式军体拳第7招》装饰器模式 Decorator——动态叠加对象能力