装饰模式

装饰模式用于动态地给一个对象添加一些额外的职责，它可以理解为继承的替代方案。就增加功能来说，装饰模式比生成子类更加灵活。

比如一家奶茶店，店里的奶茶可以加各种配料，这时应该怎么实现呢？

一种方案是先构造一个奶茶抽象类，然后生成各种子类如珍珠奶茶、红豆奶茶、椰果奶茶 ...... ，但事实上一杯奶茶奶茶里可以添加多种配料，比如珍珠野果奶茶，如果店里的配料很多，排列组合之后要生成的子类就更多了，所以继承对于这个问题不是一个好的解决方案。

这时就可以采用装饰者模式。定义一个奶茶接口 TeaWithMilk 、定义一个Decorator 抽象类（该类实现了TeaWithMilk，同时将设置TeaWithMilk 为可以被继承的成员变量，同时定义一个setTeaWithMilk函数或在构造函数中设置该成员变量），珍珠奶茶、红豆奶茶等作为 Decoreater 的子类，重写setTeaWithMilk函数。实例化一个奶茶对象（该对象应实现TeaWithMilk）。这时就可以将奶茶对象作为参数传递给珍珠奶茶等子类的实例，想要再加入椰果时，就将珍珠奶茶的实例传入椰果奶茶的实例。

装饰者模式的结构如下：

 

主要角色为：

                        抽象构件(Component)角色：给出一个抽象接口，已规范准备接收附加责任的对象。、

                        具体构件(ConcreteComponent)角色：定义一个将要接收附加责任的类

                        装饰(Decorator)角色：持有一个构件(Component)对象的实例，并定义一个与抽象构件接口一致的接口。

                        具体装饰(ConcreteDecorator)角色：负责给构件对象“贴上”附加的责任

 

装饰模式利用 SetComponent 函数或 构造函数 对对象进行包装；

使用装饰模式，意味着每个装饰对象的实现与如何使用这个对象就分开了，每个对象只需要关心自己的功能，不需要关心自己要被怎样添加到装饰链中。或者说可以把类中的装饰功能从类中去除，简化原有的类；可以有效区分类的核心功能和和装饰功能，且去除相关代码中的重复逻辑。

如数据本身是一个类，而加密数据和过滤数据可以作为数据的装饰而独立出来。

在实际操作中，如果只有一个concreteComponent类，可以将其与Component类合并，让Decorater类继承concreteComponent类；如果只有一个ConcreateDecorate类，也可以将其与Decorater类合并。