装饰模式（Decorator）是一种结构型设计模式。

它允许动态地为对象添加额外的职责，而无需修改其原有代码。 它通过将对象包装在装饰者类中，以透明的方式扩展功能，避免了静态继承带来的类爆炸问题， 符合开闭原则（对扩展开放，对修改关闭）。

小结

• 装饰模式是为已有功能动态地添加更多功能的一种方式。不使用装饰模式时，当系统需要新功能的时候，是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或主要行为，在主类中加入了新的字段，新的方法和新的逻辑，从而增加了主类的复杂度，而这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要。而装饰模式却提供了一个非常好的解决方案，它把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择地、按顺序地使用装饰功能包装对象了。

• 装饰模式的优点，把类中的装饰功能从类中搬移去除，这样可以简化原有的类。有效地把类的核心职责和装饰功能区分开了。而且可以去除相关类中重复的装饰逻辑。

优点

• 动态扩展：运行时添加或移除功能，灵活性强。
• 单一职责：每个装饰类只关注一个功能，代码更清晰。
• 替代继承：避免多层继承导致的类膨胀问题。
• 开闭原则：无需修改原有代码即可扩展功能。

缺点

• 复杂度增加：多层装饰可能导致代码结构复杂，调试困难。
• 性能开销：装饰链较长时，可能影响执行效率。
• 依赖管理：装饰者需要与原对象保持接口一致，否则可能破坏调用逻辑。

适用场景

• 动态功能扩展：如为对象添加日志、缓存、权限检查等。
• 不可修改的第三方库：在不修改源码的情况下增强功能。
• 组合替代继承：需要多维度扩展对象功能时。
• 中间件机制：如 Express 的中间件、Redux 的 enhancer。