软件开发中的装饰器模式是什么呢？

装饰器模式就是动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。

1.装饰器模式允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构性模式，它是作为现有的类的一个包装。

2.这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。

3.我们通过下面的实例来演示装饰器模式的用法。其中，我们将把一个形状装饰上不同的颜色，同时又不改变形状类。

圣诞节快到了，很多小伙伴都会装饰圣诞树，我们会往树上挂上很多有节日气氛的装饰品，但我们并不会破坏这棵树原有的结构，这便是我们生活中的装饰器模式。

JavaScrip t中装饰器模式的一个很好地表现便是 装饰函数 。比如我们在维护一个项目的时候，突然来了新的需求，需要我们往原来的函数中添加新的功能。原来的函数是以前的同事写的又经过好几个人的手，里面的实现非常杂乱，最好的方法是尽量不去改动原函数，通过保存原引用的方式去改写这个函数。

比如我们想给 window 绑定 onload 事件，但是如果这个事件之前有人绑定过，我们直接写就会覆盖掉之前事件中的行为。为了避免覆盖掉之前的 window.onload 函数中的行为，我们一般都会先保存好原先的 window.onload ，把它放入新的 window.onload 里执行

新的 window.onload 函数就是我们的装饰函数。

上面这种方式存在以下两个问题：

为了解决这两个问题，我们用 高阶函数 来装饰函数。

我们在原来的函数上添加新行为，添加的新行为要么先于函数执行，要么后于函数执行。我们实现两个方法—— Function.prototype.before 给函数添加先于函数执行的新行为， Function.prototype.after 给函数添加后于函数执行的新行为：

再回到上面 window.onload 的例子，我们可以这样写：

假如我们给搜索按钮添加埋点事件，需要做两件事，一是实现搜索功能，另一个是上报数据。

在第二种实现方式（装饰器模式实现）中，我们对按钮职责进行了更细的划分，保证了函数单一职责原则。

下面是一个我们封装的 axios 请求

现在需要给每个请求都加上 token 参数

在装饰器模式实现方式中我们没有改变原函数，原函数是一个比较纯净的单一职责函数，提高了request函数的可复用性。

装饰器模式是允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。通俗的来讲，就是一个对象嵌入到另一个对象中去，实际上相当于这个对象被另一个对象包装起来，形成一条包装链。

主要是解决为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。优点是，装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

应用场景：（a）在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。 (b) 需要动态地给一个对象增加功能，这些功能也可以动态地被撤销。 当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。

在装饰器模式中的角色有：

抽象构件(Component)角色：给出一个抽象接口，已规范准备接收附加责任的对象。具体构件(ConcreteComponent)角色：定义一个将要接收附加责任的类。装饰(Decorator)角色：持有一个构件(Component)对象的实例，并定义一个与抽象构件接口一致的接口。具体装饰(ConcreteDecorator)角色：负责给构件对象“贴上”附加的责任。

---