装饰者模式实战：告别继承爆炸，用组合优雅扩展功能

设计模式里如果只能让我挑一个，落实到日常业务中最出效果的，我大概率会选装饰者模式。它解决的不是那种百年一遇的架构难题，而是每天都在发生的需求——给一个对象动态加功能，但又不想动它原来的代码。第一次用继承去堆功能，你会觉得很爽，等子类多到连自己都认不全的时候，就该回头看看装饰者了。这篇文章我打算从继承失控的真实痛点讲起，把装饰者模式的结构、代码、业务场景和踩坑经验一次说透，适合刚接触设计模式的读者，也适合写了很多业务代码、想理清封装思路的开发者。

1. 装饰者模式到底是什么——从一个真实痛点说起

1.1 继承为什么会让代码走向失控

很多项目是从一个简单的类开始的。比如消息通知，最开始只有邮件通知，一个类搞定。后来产品说要加短信通知，你心想简单，抽个接口，写两个实现类。再后来需求开始升级，有人要发带附件的邮件，有人要发加密短信，还有人要既带附件又带签名。如果继续用继承，组合的类别数量就会呈爆炸式增长。

以通知功能为例算算账：2种基础渠道（邮件、短信），3种附加能力（附件、加密、签名）。用继承来做，你需要创建6个组合类。如果基础渠道变成4种，附加能力变成5种，组合类的数量就是4乘5等于20个。这还只是单层扩展，如果附件和加密能叠加，类数量会直接变成指数级。我见过最夸张的代码里有十几个类，命名全是 EmailWithAttachmentEncrypted、SmsWithSignatureEncrypted 这种组合，改一个基础逻辑，所有相关子类全要重新编译。

这还只是类爆炸的问题。真正让人头大的是继承引入了强耦合，附加能力被固化在类的层级里，运行时想换一套组合根本做不到。产品经理说“今天先发加密邮件，明天只发带附件的短信”，代码层面就要增加新类，改动范围根本无法控制。用继承扩展功能这条路，越往后走越是给自己埋雷。

1.2 装饰者模式的破局思路

装饰者模式给出的解法非常朴素：不通过继承来扩展，而是用组合层层包装。核心思想是把附加功能拆成独立的小类，每个小类只做一件事，然后在运行时动态组装。

你可以把这种组装方式想象成俄罗斯套娃。最里面是一个基础对象，外层一层套一层，每一层负责一种附加能力。无论套了多少层，客户端拿到的仍然是同一个接口类型，调用方法时内层外层会依次执行，最终得到一个完整的结果。

这个思路有两个关键点。第一，基础类和装饰类实现的是同一个接口，所以客户端根本不需要关心自己拿到的是原始对象还是被包装过的对象。第二，装饰类里持有被装饰对象的引用，调用时先做自己那部分事情，再把请求传递下去。这样功能可以无限叠加，而且互不干扰。

这套设计完美契合了开闭原则——对扩展开放，对修改关闭。要增加一个新功能时，你只需要新增一个装饰类，不用改动任何已有的类。对比继承那一长串类，改动量完全不在一个量级。我第一次把项目的价格计算从继承重构为装饰者时，最大的感受是终于不用再为每一个组合场景新建类了。

2. 装饰者模式的结构与代码实现

2.1 四个角色，先看清楚谁是谁

装饰者模式涉及四个角色，理解他们是掌握整个模式的前提。

实际代码里，抽象装饰类是一个让很多初学者困惑的存在。既然装饰器本质上也是一个Component，为什么不直接让具体装饰类去实现接口，而要中间夹一个抽象装饰类？这背后是一个很实在的考量：所有具体装饰器都需要持有被装饰对象的引用，而且这个引用必须通过构造函数注入。如果把这些公共逻辑抽到抽象装饰类里，每个具体装饰器只需要写自己那部分增强逻辑，代码会清爽很多。

抽象装饰类的另一个作用是把装饰器的类型收敛起来。你可以在代码里看到某个类是 CoffeeDecorator 的子类，一眼就知道它是用来装饰咖啡的，而不是去实现一个宽泛的接口，语义更明确。

2.2 用一杯咖啡讲透装饰者模式

代码永远是理解设计模式最快的路径。我用一个咖啡点单的场景来讲，这种场景大家都有体感。假设一杯原味咖啡10元，可以加奶加糖，每种配料价格不同。

先定义组件接口和基础组件：

typescript复制interface Coffee {
  cost(): number;
  getDescription(): string;
}

class SimpleCoffee implements Coffee {
  cost(): number {
    return 10;
  }

  getDescription(): string {
    return "原味咖啡";
  }
}

接着定义抽象装饰类，它实现接口，同时持有Coffee引用：

typescript复制abstract class CoffeeDecorator implements Coffee {
  protected coffee: Coffee;

  constructor(coffee: Coffee) {
    this.coffee = coffee;
  }

  abstract cost(): number;
  abstract getDescription(): string;
}

然后是两个具体装饰类，分别对应加奶和加糖：

typescript复制class MilkDecorator extends CoffeeDecorator {
  cost(): number {
    return this.coffee.cost() + 3;
  }

  getDescription(): string {
    return this.coffee.getDescription() + "，加奶";
  }
}

class SugarDecorator extends CoffeeDecorator {
  cost(): number {
    return this.coffee.cost() + 2;
  }

  getDescription(): string {
    return this.coffee.getDescription() + "，加糖";
  }
}

客户端的使用方式是这样的：

typescript复制let coffee: Coffee = new SimpleCoffee();
coffee = new MilkDecorator(coffee);
coffee = new SugarDecorator(coffee);

console.log(coffee.getDescription()); // 原味咖啡，加奶，加糖
console.log(coffee.cost()); // 15

关键就在这段客户端代码里。第一行创建基础对象，后面两行做装饰，但变量的静态类型始终是 Coffee。后续代码调用 cost() 时，SugarDecorator 会先调用 MilkDecorator 的 cost，MilkDecorator 再调用 SimpleCoffee 的 cost，计算结果一层层往上返回，整个过程客户端完全无感知。

我给一个小建议：装饰器里的 getDescription() 一定不要直接返回字符串常量，而要拼接被装饰者的描述。否则当你组合多个装饰器时，最终描述会丢失前面的信息。这个细节我在实际项目里踩过，一开始图省事，结果被测试同学抓了好几个bug。

2.3 装饰顺序为什么影响结果

装饰者模式中，装饰器的组合顺序直接影响最终结果，这一点常被新手忽略。加奶加糖的场景，顺序影响的只是描述文本。但在真实业务里，顺序影响的是真金白银。

以订单价格计算为例，假设商品原价100元，有会员95折优惠，还有一张满100减20的优惠券。先套折扣再减券：100打95折得到95元，再减20元，最终75元。先减券再套折扣：100减20得到80元，再打95折，最终76元。虽然只差1元，但业务规则不允许“差不多”。

这就要求你在设计阶段就明确装饰规则。通常做法是写清楚装饰器的被装饰对象是上一个装饰器处理的结果，顺序一旦确定就不能随意调换。我在项目里把装饰顺序放在了配置中心，用配置项控制哪一个先执行，这样产品调整规则时不用发版本，改配置就好。

3. 设计背后的关键决策解析

3.1 为什么装饰者必须实现同一接口

这是装饰者模式与适配器模式最本质的区别。适配器的核心是接口转换，把一个接口转成客户端想要的另一个接口，类型发生了变化。装饰者的核心是接口一致性，无论内部包了多少层，对外暴露的一定是同一个接口。

为什么要刻意维持这种一致性？因为客户端不想知道对象有没有被装饰。想象一下，如果装饰器改变了接口类型，客户端就得区分原始对象和装饰后对象，消费方代码会出现大量 if 分支来分情况处理，装饰者带来的透明性就荡然无存。

这个设计选择带来的好处是，你可以在任意层装饰器上继续装饰，组合能力没有上限。同时替换实现变得简单，想不要某个功能时，只需要在组装处去掉那一层，其它代码不用改动。

3.2 构造注入和透明性的重要性

关于被装饰对象的传递方式，我看到过有人在装饰器里直接 new 一个被装饰对象，这是最典型的错误。装饰器必须通过构造函数接收被装饰者，而不是自己创建。

原因有两个。第一，依赖倒置原则要求装饰器依赖抽象接口，而不是具体实现。如果装饰器自己 new 对象，它就和具体类绑定了，装饰器本身也失去了复用价值。第二，装饰器的职责是增强，不是创建。被装饰者是外部组装好的，装饰器只负责透传调用。如果你让装饰器自己创建被装饰对象，一个装饰器只能装饰固定类型，组合能力被彻底破坏。

透明性还体现在异常处理层面。装饰器里如果捕获了异常，处理完以后应该考虑是否抛出、是否包装，而不是擅自吞掉。我曾经在一个日志装饰器里把所有异常都 catch 了，结果线上接口报错完全看不出来，排查了很久才发现是日志装饰器把异常消费掉了。这件事让我明白了一个道理：装饰器可以增强功能，但不能改变原本的控制流语义。

3.3 装饰者模式与代理模式、策略模式的区别

很多人在实际项目中会分不清装饰者模式和代理模式，因为两者都是通过包装对象来扩展行为。它们的核心区别在意图上。

代理模式的核心是控制访问。代理可以延迟创建真实对象、做权限校验、记录访问日志，代理和被代理对象不需要实现同一个接口。装饰者模式的核心是增强功能。装饰者必须和被装饰对象实现同一个接口，它不控制访问，只负责在请求传递过程中增加职责。

策略模式则完全不同，它解决的是算法替换的问题。同一个接口，多种实现，运行时选择一种。装饰者模式解决的是职责叠加的问题，多个装饰器可以同时作用在一个对象上。一个典型的对比场景是价格计算：如果只是选择一种折扣方式，用策略模式；如果折扣、优惠券、满减要叠加使用，装饰者模式更合适。

4. 实操过程：真实业务场景下的落地方式

4.1 场景：订单系统的价格计算

把模式落进真实业务，才真正算学会。我在一个电商订单系统里用装饰者模式重写过价格计算模块，整个思路可以分享出来。

原始价格计算代码是一长串 if else，每次加新促销就要改主流程，测试回归都要小心翼翼。用装饰者重构后，先定义价格组件接口：

typescript复制interface PriceCalculator {
  calculate(amount: number): number;
}

class BasePrice implements PriceCalculator {
  calculate(amount: number): number {
    return amount;
  }
}

然后定义两个具体装饰器：

typescript复制class MemberDiscountDecorator extends PriceCalculatorDecorator {
  private readonly discountRate: number;

  constructor(calculator: PriceCalculator, discountRate: number) {
    super(calculator);
    this.discountRate = discountRate;
  }

  calculate(amount: number): number {
    return this.calculator.calculate(amount) * this.discountRate;
  }
}

class CouponDecorator extends PriceCalculatorDecorator {
  private readonly couponAmount: number;

  constructor(calculator: PriceCalculator, couponAmount: number) {
    super(calculator);
    this.couponAmount = couponAmount;
  }

  calculate(amount: number): number {
    const current = this.calculator.calculate(amount);
    return current > this.couponAmount ? current - this.couponAmount : 0;
  }
}

组装过程由工厂或配置统一管理：

typescript复制let calculator: PriceCalculator = new BasePrice();
calculator = new MemberDiscountDecorator(calculator, 0.95);
calculator = new CouponDecorator(calculator, 20);

这个设计最爽的地方，在于增加新促销时完全不需要动已有代码。产品说下个月要加“满300减50”，你只需要新增一个 FullReductionDecorator，在工厂里按规则往链上接一层即可。原有的价格计算流程一个字符都不用改。

4.2 扩展：日志、缓存与重试装饰器

价格计算只是装饰者模式在业务层的应用，它最大的舞台其实在横切关注点领域，也就是日志、缓存、重试这类与核心业务无关、但每个接口都需要的能力。

日志装饰器是最好实现也最容易见效的。它做的事情很简单：调用前记录入参，调用后记录出参和耗时。把这段逻辑写进业务代码里会非常冗长，抽成装饰器以后，只用在需要的地方包一层。

缓存装饰器的思路更实用。每次调用真实对象前，先检查缓存，命中就直接返回，没有命中再调用真实对象，并写回缓存。key 的生成规则需要根据业务灵活处理，比如按方法名和参数序列化拼接。缓存逻辑单独放在装饰器里，和业务完全解耦。

重试装饰器我建议在分布式项目里考虑。真实对象调用失败时，捕获异常后按预设的次数做重试，中间加一点退避时间。重试次数是3次还是5次，应该作为参数传入，不要写死在装饰器里。用装饰器做重试的好处是，只有特定的远程调用才需要重试，本地调用直接就是原始对象，代码表达非常清晰。

4.3 从Java I/O到前端中间件，装饰者无处不在

也许你已经发现，Java I/O 包就是装饰者模式最经典的教科书案例。

java复制BufferedReader reader = new BufferedReader(
    new InputStreamReader(
        new FileInputStream("test.txt"), "UTF-8"));

这一行代码里有三层装饰。FileInputStream 负责读取文件字节，InputStreamReader 负责字节转字符，BufferedReader 负责缓冲提升性能。每一层只做好自己的事，组合起来就是完整的业务能力。如果当初用继承来实现这些组合，类数量会多到无法维护。

到了前端领域，React 的高阶组件（HOC）本质上也是装饰者思想的体现。你写一个 withLogger、withRouter 函数，名为接收组件、返回新组件，本质就是在原来的组件上包装一层功能。Koa 和 Express 的中间件机制也和装饰者传递请求的思想一脉相承，每个中间件决定是否处理请求、是否把请求往下传。

可以说，装饰者模式是那种你可能没意识到名字、但天天在用的设计。理解它之后，你看到类似的包装结构会自动识别出其中的设计逻辑，写代码时也会更自然地用组合去表达叠加逻辑。

5. 常见问题与排查技巧实录

5.1 从一次诡异的功能丢失说起

有一回我在项目里给支付接口加了缓存装饰器，上线后发现部分订单金额变成了 0。排查了半天，最后发现是缓存装饰器执行了真实支付方法之后才写缓存，而支付方法本身有副作用，第二次命中缓存时直接跳过了真实调用，业务流程不完整导致数据异常。

这个问题的根子在于，装饰器的职责应该是为无副作用的查询类操作做缓存，用在有副作用的写操作上需要非常谨慎，不能用缓存跳过真实的业务执行。排查这类问题时，第一件事就是确认装饰器的调用链是否完整。如果一个装饰器没有调用被装饰者的方法，链路就断了，后续所有装饰器都不会执行。

我自己常用的排查方式是在装饰器的入口和出口各打一条日志，带上被装饰对象的类型信息。日志打出来以后，调用顺序一目了然，哪一层没有往下传，哪一层抛了异常，都能很快定位。

5.2 对象身份与调试地狱

装饰器叠加太多层之后，调试过程会变得有些痛苦。断点打在内层类里，调用栈被层层包装包裹，变量监视窗口看到的是一个个装饰器对象，想找到最终的原始对象要翻半天。

更让人头疼的是对象相等性问题。如果原始对象定义了 equals 和 hashCode，被装饰以后，外层对象和原始对象在逻辑上可能是同一个业务对象，但 equals 方法比较结果往往是 false。这会导致集合判断、缓存去重这些逻辑出现预料之外的结果。

针对这个问题，我的建议是控制装饰器的层数，尽量不要超过3层。超过3层，组合复杂度会让可读性急剧下降。如果确实需要很多增强功能，可以把若干个装饰器合并为一个，在装饰器内部做多个职责的编排，牺牲一点单一原则，保住可维护性。

5.3 装饰者模式避坑速查表

最后整理一个我在实际项目中总结的速查表，方便遇到问题时快速对照：

我还想特别提一点，装饰器类的命名一定要带上 Decorator 后缀，比如 CacheDecorator、LogDecorator。团队协作时，别人看到类名就知道这是一个装饰器，会自动预期它的行为是包装并透传。命名上的清晰自解释，比起注释更能避免误用。

5.4 一个小建议：先写接口，再写装饰器，最后写客户端

根据我个人经验，用装饰者模式重构老代码或者写新功能时，最稳的落地顺序是：先定义组件接口，确保核心方法稳定下来；然后写基础实现类，让业务先跑通；再抽公共装饰器抽象类，把被装饰者的引用管理收拢；接着依次实现具体装饰器，每加一个就测试一个；最后才在客户端组装，印证装饰器组合后的整体行为。

这个顺序能帮你避免一个常见失误：一开始就奔着装饰器去设计，结果发现接口的边界没划好，装饰器和基础类来回改。先把基础路径跑通，再逐步叠加，每一步都有验证点，出问题时也能快速定位到具体是哪一层引入的。

我在项目里做的就是先把基础价格计算跑通，然后每加一个促销装饰器就手动算一遍结果。这个习惯让我在重构价格模块时几乎没有收到过客诉。设计模式的意义不是炫技，而是让代码在面对变化时依然稳得住。装饰者模式是我用过的模式里，投入产出比最高的一位。