装饰器模式：动态增强对象功能
装饰器模式：动态增强对象功能
在面向对象开发中，我们常面临一个需求：在不修改原有类代码的前提下，为对象动态添加新的职责。继承看似能解决问题，但会导致子类爆炸、静态绑定、违反开闭原则。装饰器模式正是为此而生——它通过组合而非继承，提供一种灵活、透明的对象功能扩展机制。
什么是装饰器模式
装饰器模式是一种结构型设计模式，它允许你将对象放入一个特殊的包装器对象中，从而在运行时动态地为原对象绑定新的行为。这个包装器（即装饰器）与原对象实现相同的接口，使得客户端在使用时，可以像操作原对象一样操作被装饰后的对象。
其核心思想是：用组合替代继承，将扩展功能层层“包裹”在原对象四周，实现“开箱即用”的能力叠加。每一个装饰器只关注自己新增的责任，并通过委托原对象完成核心任务。
模式结构
一个典型的装饰器模式包含四种角色：
- 组件（Component）：定义了被装饰对象和装饰器的共同接口。
- 具体组件（Concrete Component）：实现接口的基础对象，是被装饰的原始实体。
- 装饰器（Decorator）：抽象类或基类，持有一个指向组件对象的引用，并实现组件接口。通常将请求转发给该引用。
- 具体装饰器（Concrete Decorator）：真正添加额外职责的类，在调用被装饰对象的方法前后，可以加入自己的逻辑。
+----------------+
| Component |<-------------------+
+----------------+ |
| + operation() | |
+----------------+ |
△ △
| |
+----------------+ +------------------+
| ConcreteComp | | Decorator |
+----------------+ +------------------+
| + operation() | | - component: Component
+----------------+ | + operation() |
+------------------+
△
|
+------------------------+
| ConcreteDecoratorA |
+------------------------+
| + operation() |
| + addedBehavior() |
+------------------------+
- 客户端通常创建一份具体组件，然后用任意数量的装饰器嵌套包装它，最终调用最外层装饰器的
operation()。
现实世界的类比：一杯咖啡的定制过程
你可以把装饰器模式理解为一杯咖啡的制作流程。基础组件是一份浓缩咖啡，装饰器是各种调料（牛奶、摩卡酱、奶油等）。每添加一种调料，都会“包裹”原来的饮料，使其获得新的风味和价格。
class Drink:
def cost(self):
pass
class Espresso(Drink):
def cost(self):
return 10
class MilkDecorator(Drink):
def __init__(self, drink):
self._drink = drink
def cost(self):
return self._drink.cost() + 3
class MochaDecorator(Drink):
def __init__(self, drink):
self._drink = drink
def cost(self):
return self._drink.cost() + 5
# 客户端使用
order = Espresso()
order = MilkDecorator(order)
order = MochaDecorator(order)
print(order.cost()) # 输出 18
每种装饰器都持有一个 Drink 引用，并能够在上层饮料成本上增加自己的价格。你可以在不修改任何已有类的前提下，自由组合调料。
动手实现：一个文本格式化装饰器
下面用 JavaScript 示例演示如何用装饰器动态增强一个 TextMessage 对象的功能。
// 组件接口
class TextMessage {
getContent() {
throw new Error("子类必须实现getContent方法");
}
}
// 具体组件
class PlainText extends TextMessage {
constructor(text) {
super();
this.text = text;
}
getContent() {
return this.text;
}
}
// 基础装饰器
class MessageDecorator extends TextMessage {
constructor(message) {
super();
this.message = message;
}
getContent() {
return this.message.getContent();
}
}
// 加密装饰器
class EncryptedDecorator extends MessageDecorator {
getContent() {
const content = super.getContent();
// 模拟加密：对每个字符进行位移
return content.split('').map(c => String.fromCharCode(c.charCodeAt(0) + 1)).join('');
}
}
// 压缩装饰器
class CompressedDecorator extends MessageDecorator {
getContent() {
const content = super.getContent();
// 模拟压缩：移除所有空格
return content.replace(/\s/g, '');
}
}
// 使用示例
let msg = new PlainText("hello world");
msg = new EncryptedDecorator(msg);
msg = new CompressedDecorator(msg);
console.log(msg.getContent()); // 输出加密并压缩后的结果
通过嵌套装饰器，我们实现了功能的任意组合，且每个装饰器的职责单一，非常容易测试和扩展。
装饰器模式的适用场景
- 需要在不影响其他对象的情况下，动态、透明地给单个对象添加职责。
- 对象的功能扩展在运行时决定，且组合方式多变。
- 不希望通过继承和修改原有代码来实现功能增强，以遵循开闭原则。
- 希望将一个大类拆分为多个独立的小类（单一职责），通过组合达到同样效果。
典型应用包括：Java I/O 流（BufferedInputStream 装饰 FileInputStream）、Python 的 @staticmethod 装饰器、前端 UI 组件的装饰（如给按钮添加提示、权限控制）等。
优点与局限
优点
- 灵活性与可扩展性：比静态继承更弹性，可在运行时添加或移除职责。
- 遵循开闭原则：引入新装饰器无需修改已有代码。
- 单一职责：每个装饰器专注一个功能，便于理解和维护。
- 组合而非继承：避免“类爆炸”，功能组合数远超继承体系。
局限
- 系统复杂度增加：会产生许多小对象，调试时可能难以理清嵌套关系。
- 装饰器与组件依赖相同的接口：若组件接口不稳定，所有装饰器都需修改。
- 客户端需要了解组合顺序：某些功能对顺序敏感（如先加密后压缩）。
装饰器模式 vs. 其他模式
- 与代理模式：代理主要控制访问，装饰器侧重增强功能。尽管结构相似，但目的不同。
- 与适配器模式：适配器改变接口以匹配客户端需求，装饰器则保持接口不变、增强功能。
- 与策略模式：策略改变对象的内核（算法可替换），装饰器改变对象的外壳。
- 与继承：继承是编译时静态扩展，装饰器是运行时动态组合；继承产生子类，装饰器产生关联对象。
总结
装饰器模式以一种优雅而强大的方式，让我们能够动态地、可组合地为对象叠加功能，同时保持系统的高度可维护性。它教会我们多用组合、少用继承，在面对多变的需求时，用“一层层包装”替代“一个个子类”。理解并善用这一模式，能显著提升代码的灵活性和设计质量。
你现在就可以在自己熟悉的编程语言中，尝试用装饰器模式为某个基础服务添加日志、缓存、权限校验等横切关注点。你会发现，随着装饰器的累积，整个系统的功能会像搭积木一样被轻松构建起来。