装饰者模式：动态叠加职责，告别子类爆炸的设计之道

装饰者模式这个名字，听着像某种装修手法，其实它是面向对象设计模式里最贴近日常场景的一个。我第一次对它有感觉，不是在读设计模式的书，而是在改一段全是 if-else 的下单结算代码时被逼出来的。那会儿需求是这样的：订单要能叠加会员折扣、满减券、加急费，还要考虑不同配送方式的附加成本，每个需求进来我就在原来的方法里再塞一个分支，几个月下来，那段代码连我自己看着都头疼。后来我意识到，这种“往一个类里不断追加职责”的做法迟早要崩，于是开始把每个变动拆成独立的装饰层，像搭积木一样动态组合，问题一下清晰了。

这篇博文就围绕装饰者模式来展开：它到底解决什么问题、核心机制是什么、真实项目里哪些地方早就用了它、和代理模式组合模式怎么区分，以及我实际踩过的坑和一直用着的判断标准。无论你是刚接触设计模式的新手，还是写了好几年业务代码想优化结构的开发者，这篇应该都能给你一些可以直接上手的参考。

1. 从一杯咖啡说起：继承扩展的边界到底在哪

1.1 一个小需求如何演变成子类爆炸

先看一个经典例子。假设你开了一家咖啡店，饮品种类不多，就两种：浓缩咖啡（Espresso）和美式咖啡（House Blend Coffee）。价格也简单，浓缩12块，美式10块。用面向对象来表达，很自然就是两个类，各自实现一个cost()方法。

但顾客不可能只喝纯咖啡，他们会说“帮我加一份奶”、“加一份摩卡”、“两份奶不要糖”。调料种类一多，问题就来了。如果按继承的思路，每一种“饮品+调料”的组合都得建一个类：

• Espresso
• EspressoWithMilk
• EspressoWithMocha
• EspressoWithMilkAndMocha
• HouseBlendWithMilk
• HouseBlendWithMocha
• HouseBlendWithMilkAndMocha
• …

这还只是2种咖啡、2种调料的情况，总共就要8个类。如果咖啡种类变成5种，调料变成8种，那总组合数是 5 × 2^8 = 1280 个类。这不是夸张，这是纯粹的数学问题——每加一种调料，组合数量就翻倍，子类数量直接指数爆炸。

我见过不少项目的早期代码就是这样：一开始只有两三个变体，大家图省事直接继承，等到变体超过十个，类的命名就开始混乱，什么SpecialOrderWithDiscountAndExpressAndGiftPack这种名字都出来了。更崩溃的是，如果某一天要调整所有含奶制品的饮品价格，你得把所有相关的子类都翻出来改一遍，漏掉一个就是线上事故。

1.2 继承的第二个硬伤：编译期就锁死了能力

子类爆炸还不是继承最隐蔽的问题。继承的扩展能力，在编译期就把对象的能力锁死了。什么意思？就是说你声明一个变量是Espresso类型，那它在运行时就只能是Espresso本身或者它的子类，它能做什么、不能做什么，在你写下那行代码的时候就已经决定好了。

但是现实的业务需求往往不是这样。一个订单是不是要加急、要不要用优惠券、配送方式是什么，这些常常是运行时根据用户选择、库存情况、甚至系统当前负载动态决定的。用继承去表达这种“运行中还不确定”的职责组合，会非常别扭：你可能得在代码里预置大量的子类去覆盖各种组合，可你根本不知道用户到底会选哪种组合。

还有一个容易被忽略的问题：深继承链的脆弱性。当继承层次超过三层，父类的任何一个方法改动都可能波及所有子类，而子类为了满足特定需求又不得不覆写父类方法，结果就是“脆弱的基类问题”。我见过一个案例，基类里加了一个默认返回false的isFreeShipping()方法，结果底下某个子类忘了覆写，用户莫名被收了运费，排查了很久才发现是继承链上某个中间层改了行为。

继承不是不好，它是静态的、单维度的扩展方式，适合“同一类东西的纵向细化”，但不适合“多个维度的横向组合”。当你要扩展的不只是“一种咖啡”，而是“咖啡 × 调料 × 杯型 × 温度 × 糖度”这种多维组合时，就得换一种思路——不是“我是什么”，而是“我包着什么”。这就是装饰者模式登场的时机。

2. 装饰者模式的骨架：组合转发把功能一层层叠上去

2.1 四个角色的分工

装饰者模式的结构其实很直白，就四个角色：

这里最核心的一个设计决策是：抽象装饰者本身也实现了同一个组件接口。正是这一条让装饰者的“套娃”成为可能——每一个装饰者包装出来的对象，类型仍然是组件接口，可以被下一个装饰者继续包装，也可以直接当作原始对象使用。

很多初学者理解不了为什么要多此一举搞一个抽象装饰者。我的理解是：它解决的是“统一”的问题。如果没有抽象装饰者，每个具体装饰者都得自己持有组件引用、自己实现接口方法，代码大量重复且容易漏实现。有了抽象装饰者，公共的“持有被装饰对象”的逻辑被收拢到一处，具体装饰者只需要专注写自己的那点增强逻辑。

另外，这个角色还暗示了一个约束：装饰者模式要求组件接口尽量简单、稳定。如果你的组件接口有二十个方法，每个装饰者都要转发二十个方法，这个模式的成本就很高。我后面会专门讲这个问题。

2.2 一段能跑的代码：咖啡加奶加摩卡

理论说再多，不如看一段能跑的代码。我用Java来写，因为Java在类型表达上最严谨，能把这个结构讲透。

先定义组件接口和具体组件：

java复制// 组件接口：饮品
public interface Beverage {
    String getDescription();
    double cost();
}

// 具体组件：浓缩咖啡
public class Espresso implements Beverage {
    @Override
    public String getDescription() {
        return "浓缩咖啡";
    }

    @Override
    public double cost() {
        return 12.0;
    }
}

// 具体组件：美式咖啡
public class HouseBlend implements Beverage {
    @Override
    public String getDescription() {
        return "美式咖啡";
    }

    @Override
    public double cost() {
        return 10.0;
    }
}

然后定义抽象装饰者，它实现了Beverage接口，同时持有一个Beverage引用：

java复制// 抽象装饰者：调料装饰器
public abstract class CondimentDecorator implements Beverage {
    protected Beverage beverage;

    public CondimentDecorator(Beverage beverage) {
        this.beverage = beverage;
    }
}

这里注意，CondimentDecorator只做了一件事：把要装饰的对象存下来。至于getDescription()和cost()，它并没有强制实现，子类会各自处理。

接下来是两个具体装饰者：

java复制// 具体装饰者：加奶
public class Milk extends CondimentDecorator {
    public Milk(Beverage beverage) {
        super(beverage);
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + "，加奶";
    }

    @Override
    public double cost() {
        return beverage.cost() + 3.0;
    }
}

// 具体装饰者：加摩卡
public class Mocha extends CondimentDecorator {
    public Mocha(Beverage beverage) {
        super(beverage);
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + "，加摩卡";
    }

    @Override
    public double cost() {
        return beverage.cost() + 4.0;
    }
}

在客户端组装时，就像套娃一样一层层包起来：

java复制public class CoffeeShop {
    public static void main(String[] args) {
        // 一杯浓缩咖啡，加奶，加摩卡
        Beverage beverage = new Espresso();
        beverage = new Milk(beverage);
        beverage = new Mocha(beverage);

        System.out.println(beverage.getDescription());
        System.out.println(beverage.cost());
    }
}

输出结果：

code复制浓缩咖啡，加奶，加摩卡
19.0

这个计算过程是怎么跑的呢？cost()调用会沿着装饰链一层层往里传：最外层的Mocha调用beverage.cost()，这个beverage是Milk对象，Milk又调用它内部的beverage.cost()，最后传到Espresso返回12.0，然后逐层加价返回。最终结果是 12 + 3 + 4 = 19。

2.3 递归调用链与“包装”的本质

从上面这个例子能看出，装饰者模式的本质是一种“递归调用”：外层装饰者在调用内层对象的方法之后、之前或者前后，附加自己的行为。这种递归和函数式编程里的高阶函数非常像——你把一个函数传进另一个函数，返回的函数仍然可以被继续传入，直到你想停的地方。

这个递归特性给设计带来两个好处。

第一是动态组合。在运行期想加几个装饰就加几个，想按什么顺序加就按什么顺序加，完全不需要预先为所有组合创建类。订单系统里，如果用户决定加急配送，就new ExpediteDecorator(order)；如果用户又加入了会员折扣，就再包一层new MemberDiscountDecorator(expeditedOrder)。这种灵活性是继承完全给不了的。

第二是开闭原则。新增一种调料，只需要新增一个装饰者类，不用动任何已有的类。原有的Espresso、HouseBlend、甚至已经写好的Milk装饰者，全都无需修改。这一点看起来简单，在长期维护的项目里价值巨大——你不需要为了新功能去回归测试所有旧功能。

但这里也要说句公道话：递归调用链在带来灵活性的同时，也引入了隐性的复杂度。你看到new Mocha(new Milk(new Espresso()))，能一眼看出它的行为，但如果在真实的业务代码里，装饰层的构造分散在不同方法甚至不同服务里，运行时的行为就没那么直观了。这也是后面会讲到的过度装饰问题的一个根源。

3. 真实项目中的装饰者思维：从Java IO到中间件再到HOC

3.1 Java IO：设计模式书里最标准的装饰者样板

如果你去看JDK源码，会发现java.io包几乎就是装饰者模式的“样板房”。很多人第一次看到new BufferedInputStream(new FileInputStream("test.txt"))这种写法时，都会觉得奇怪：为什么不直接给FileInputStream加一个buffer属性？

原因就在于装饰者模式的设计哲学：每个类只专注自己的核心职责，其他能力通过包装来叠加。FileInputStream只负责从文件读字节，BufferedInputStream只负责提供缓冲，两者解耦。如果你想读加密的文件，可以再加一层CipherInputStream；如果你想按基本类型读取数据，可以再加一层DataInputStream。组合方式多到你不需要为每一种功能组合写一个专用类。

Java IO的这套设计其实还有一个隐藏的用意：它是从运行时动态性出发的。同一个InputStream对象，在读取时可能需要根据文件格式、网络状态等条件决定要不要套缓冲层。如果一个类把所有能力都揉在一起，就很难应对这种运行时的策略切换。

不过Java IO也让我们看到装饰者模式的另一面：类数量暴增。InputStream体系里有几十个类，新手光看类名就能看晕。这是装饰者模式的固有代价——类多、层次深、新手不友好。但如果你写过一段时间的Java IO，习惯了“一层层套”的思维，会发现这个设计其实非常优雅。

3.2 Web中间件：洋葱模型本身就是一套装饰链

如果说Java IO是装饰者模式在类库里的经典应用，那Web框架的中间件机制则是装饰者模式在工程实践中最接地气的一个变体。

以Koa为例，它有一个著名的“洋葱模型”。请求进来时，会依次经过注册的中间件，每个中间件都可以在await next()之前做事情（请求前处理），也可以在await next()之后做事情（请求后处理）。这本质上就是一套装饰链：

javascript复制app.use(async (ctx, next) => {
    console.log('日志中间件：请求开始');
    await next();
    console.log('日志中间件：请求结束');
});

app.use(async (ctx, next) => {
    const start = Date.now();
    await next();
    ctx.set('X-Response-Time', Date.now() - start);
});

app.use(async (ctx) => {
    ctx.body = 'Hello World';
});

每一个中间件，包装的都是“下一个中间件”，这跟new BufferedInputStream(new FileInputStream(...))的嵌套结构一模一样。日志中间件、耗时统计中间件、鉴权中间件、缓存中间件，每个中间件只负责一件事，然后通过注册顺序把整个请求链路串起来。

这种设计的最大好处是可插拔。想加一个功能，新增一个中间件文件app.use(metricsMiddleware)就行，不用改业务代码；想下线一个功能，注释掉一行就好。业务开发里，这种灵活度极其实用。

很多团队在最初设计中间件的时候，容易把中间件写得越来越“胖”，一个中间件里既做日志又做鉴权还做耗时统计。从装饰者的角度来说，这相当于一个装饰者干了三件事，导致它无法被单独组合到其他链路里。如果你发现中间件不好复用，可以想想是不是违反了“单个装饰者只加一种职责”这个原则。

3.3 Python装饰器与React高阶组件：装饰者思想的跨语言映射

装饰者模式的思想并不局限于Java这样严格面向对象的语言。Python里用语法糖直接支持了装饰器（decorator），而且用起来比Java的类装饰者更轻量：

python复制import functools
import time

def timer(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        print(f"{func.__name__} 耗时 {time.time() - start:.3f}s")
        return result
    return wrapper

@timer
def process_order(order_id):
    # 处理订单的业务逻辑
    pass

这里的@timer本质上就是把process_order函数包装进wrapper里，wrapper在调用原函数前后额外统计耗时。一层层叠加的话，可以用多个@符号实现多级装饰。逻辑和Java版装饰者完全一致，只是把“类对象”换成了“函数对象”，把“方法转发”换成了“调用原函数”。

React里的高阶组件（HOC）也是同一个套路。一个HOC是个函数，接收一个组件，返回一个新组件，新组件在渲染原组件时附加额外的props或行为：

jsx复制function withLogger(WrappedComponent) {
    return function EnhancedComponent(props) {
        console.log('组件渲染时记录日志');
        return <WrappedComponent {...props} />;
    };
}

const OrderCardWithLogger = withLogger(OrderCard);

你甚至可以withLogger(withAuth(withTheme(OrderCard)))这样几层包下来，每个HOC只关心一个横切关注点。这套模式在前端组件复用领域已经非常成熟，只是很多前端开发者没意识到，他们天天写的东西就是装饰者模式。

所以装饰者模式的本质，跟具体语言和形式无关，核心思想就一句话：在一层不改变原有接口的包装里，动态地加入新职责。接口的统一是前提，转发是手段，叠加是效果。

4. 别把装饰者和代理模式、组合模式混为一谈

4.1 装饰者与代理模式：同一个结构，完全不同的意图

结构上看，装饰者模式和代理模式极其相似：都是持有一个目标对象的引用，都在调用目标对象方法前后做一些事情。很多初学者看了两个模式的类图之后直接懵圈，这不长得一样吗？

差异在意图上，这就好比两个人都住同一栋楼，但一个住的目的是自己住，另一个的目的是把房子租出去赚钱。类图相同，但设计目标完全不同。

一个很实际的区别是：装饰者是“你主动给它加东西”，代理是“你根本不知道后面还有一层”。比如RPC框架里的服务代理、Spring AOP里的事务代理，对调用方来说是完全透明的，调用方以为自己在直接调一个本地服务，实际上请求被代理转发了。而装饰者模式里，你在代码里能看到new Milk(new Espresso())这样的显式组装过程，你对装饰链是完全知情的。

我见过有人在项目里用装饰者模式做权限控制，结果发现权限校验这种横切逻辑用代理模式更合适，因为权限不该由业务方自己决定“要不要包一层”，应该由框架统一拦截。判断方式我后面会再讲一次，这里先记住：加的是业务功能还是控制逻辑，决定你用装饰者还是代理。

4.2 装饰者与组合模式：看起来像，骨子里不同

组合模式听起来更接近，因为组合模式也是“对象里面有对象”，两者都是通过对象嵌套来组织行为。但它们的核心结构和目标不同。

组合模式的典型场景是树形结构。它有“叶子节点”和“容器节点”，两者实现同一接口，容器节点里装着一堆子节点，客户端可以一致地处理单个对象和组合对象。比如文件系统：文件夹里可以装文件，也可以装子文件夹，你可以对一个文件夹调用getSize()，它会递归统计所有子文件的大小。

装饰者模式的典型场景则是链式结构，它并不是树，而是一条垂直的“封装链”。每个装饰者只包一个对象，大多数情况下这个链是直线往下的。组合模式强调“整体与部分”的结构一致性，装饰者模式强调“职责的动态叠加”。

从代码结构上其实更好区分：组合模式的容器里通常是一个集合（List或数组），装饰者模式里持有的是单个对象引用。如果你发现自己写的“装饰者”内部持有多个被装饰对象，那大概率应该重新审视一下设计意图，你要的很可能是组合模式。

4.3 一张表理清装扮者、代理、组合、继承的关系

这里我特别想强调“扩展维度”这一行。继承是纵向的，解决的是“这个类是那个类的一种”；装饰者是横向的，解决的是“这个对象在运行时要额外具备哪些行为”。纵向扩展多了，类层次很深，维护成本上升；横向扩展多了，嵌套层级很深，运行时调式复杂。两种方式各有代价，不存在哪个永远更好。

实际项目里，我会先用组合或接口约束业务的核心骨架，再针对具体的“附加行为”用装饰者模式。核心骨架用继承表达（比如Espresso和HouseBlend都是Beverage的实现），附加行为用装饰者表达（比如Milk、Mocha都是装饰者）。这样既保留了继承对“种类”的建模能力，又避开了继承对“组合”的建模短板。

5. 我踩过的坑：顺序、透明性、还有收不住的嵌套

5.1 装饰顺序会改变结果，最常见的是加密和压缩

这是我在真实项目中踩得最深的一个坑。当时我们在做一个文件导出功能，需要把数据先压缩再加密再传输。我一开始写的代码是这样的：

java复制OutputStream out = new CipherOutputStream(
        new GZIPOutputStream(new FileOutputStream("data.gz")),
        cipher);

看起来没问题，压缩再加密嘛。但实际运行时发现，传出去的包能解压但解密失败。查了半天，发现是因为GZIPOutputStream写数据时会先写一个头部，而CipherOutputStream把包括头部在内的所有字节都加密了，接收方先尝试解密，解密后的流再解压时头部已经被破坏了一部分，导致解压失败。

正确顺序应该是先加密再压缩，也就是说让每一层都知道数据的完整含义。这个问题让我明白了：装饰顺序不是无所谓的，每一层装饰器都隐含着对数据或行为的假设，顺序错了结果就错了。

后来我在项目里专门写了一个类来封装装饰链的组装过程，保证顺序固定的部分不会被业务代码改乱。如果你不想加一个工厂类，至少在文档里把顺序约束写清楚，不然换个人维护的时候就容易踩这个坑。

5.2 instanceof和强制转型：装饰后的对象不再是原来的具体类

装饰者模式有一个“透明性”问题：从接口类型看，被装饰对象和原始对象是等价的，都能当作Beverage使用；但从具体类型看，它们完全不同。

这意味着，如果业务代码里有if (obj instanceof Espresso)这样的判断，装饰后的对象会直接跳过这个分支。我之前在一个咖啡订单系统里就遇到过：优惠逻辑判断“如果是浓缩咖啡，打九折”，结果当一个Espresso对象被Milk装饰后，instanceof Espresso返回了false，折扣没有生效，用户投诉了一片。

这个问题没有完美的解法，因为装饰者的初衷就是让客户端面向抽象接口编程。但现实是，很多老代码里充满了instanceof判断。我的处理思路有两个：

一是代码审查时坚持新代码不用instanceof判断具体类型，改用多态或者策略模式。二是如果实在无法避免，就给组件接口增加一个类型标识方法：

java复制public interface Beverage {
    String getDescription();
    double cost();
    String getBaseType();  // 返回最底层的饮品类型
}

每个装饰者返回beverage.getBaseType()，这样即使被包了几层，客户端依然能拿到原始组件的信息。这不是教科书上的正统做法，但确实能解决实际问题。

5.3 过度装饰：调试时看到一长串构造长名是什么体验

有一段时间，我们的服务调用代码大概是这样的：

java复制OrderService orderService = new TimeLogDecorator(
        new RetryDecorator(
                new CircuitBreakerDecorator(
                        new CacheDecorator(
                                new RemoteOrderService(config)))));

第一眼看上去是不是很酷？每加一个能力就包一层，非常符合开闭原则。但等出了线上问题要排查时就不酷了。你打开监控面板，看到一长串嵌套的类名，得手动辨认这是哪一层的超时、哪一层报的错误；你打一个断点，要连续step into好几次才能走到真正的业务代码；你想知道当前请求到底经过了几层装饰，还得回去数代码。

我并不是说这种写法错了，而是说装饰者模式是有使用边界的。当装饰链超过四五层，调试成本就开始指数上升。而且装饰链越长，调用链上的每个环节都可能成为性能瓶颈或故障点，排障的难度也随之增大。

我后来在项目里做了一个约定：超过三层的装饰链必须抽取成工厂方法，用语义化的名字封装整条链的组装过程：

java复制public class OrderServiceFactory {
    public static OrderService createOrderService() {
        OrderService service = new RemoteOrderService(config);
        service = new CacheDecorator(service);
        service = new CircuitBreakerDecorator(service);
        service = new RetryDecorator(service);
        return new TimeLogDecorator(service);
    }
}

这样业务代码里看不到那个吓人的嵌套构造，排查问题时可以直接看工厂方法确认装配关系。装饰者模式的优势依然在，但可维护性明显好得多。

5.4 实用的判断标准与收尾建议

写了这么多，最后分享几个我一直用来判断“要不要用装饰者模式”的标准。

第一，看功能的添加方式。如果新需求是“在现有流程上额外做一件事”，而且这个“额外的事”可能被独立复用、独立开关，那装饰者模式很合适。日志、缓存、重试、耗时统计、加价、限流，这些都是典型的可装饰行为。

第二，看职责的边界。如果一个装饰者需要访问被装饰对象的内部状态，或者需要改变被装饰对象的核心数据结构，那就不要用装饰者。装饰者模式要求各层之间有清晰的边界，适合叠加“横切关注点”，不适合修改“业务实体本身”。

第三，看对象的数量。如果业务对象的核心类型已经很多，或者组合数量可控，直接使用继承或者组合可能更简单。装饰者模式的价值在于应对“不知道会有多少组合”的场景，如果组合是有限的、固定的，硬要用装饰者反而会增加复杂度。

根据我这几年的经验，装饰者模式用得最顺手的地方，一个是IO流的组装，一个是Web中间件的编写，还有一个是给遗留系统的老接口逐步增加新能力而不想改原有实现的时候。它不会让你的代码瞬间变高级，但能在长期演进中帮你守住开闭原则这条底线。

最后再分享一个小技巧：在排查装饰链问题时，别盯着代码一层层猜，直接在具体装饰者的方法里打日志，打印当前装饰者类和被装饰者的类名，就能迅速确认请求实际经过了哪些层。这个方法我用了无数次，每次都比我对着构造长名推理快得多。