装饰器模式

为什么需要装饰器模式？

我们要买奶茶，希望加红豆和布丁。考虑如何实现这个对象的构造：

1. 把红豆和布丁作为两个成员变量：无法动态的添加成员变量
2. 创建一个成员变量表示“添加列表”，添加红豆和布丁作为元素：我们的奶茶需要一些修饰方法与红豆和布丁有关
3. 红豆和布丁作为两个独立的类，继承奶茶：如果一杯奶茶既添加了红豆又添加了布丁则无法实现这种效果

可见普通的组合和继承都无法很好的实现我们的要求。

装饰器模式概念

• Component为统一接口，也是装饰类和被装饰类的基本类型。
• ConcreteComponent为具体实现类，也是被装饰类，他本身是个具有一些功能的完整的类。
• Decorator是装饰类，实现了Component接口的同时还在内部维护了一个ConcreteComponent的实例，并可以通过构造函数初始化。而Decorator本身，通常采用默认实现，他的存在仅仅是一个声明：我要生产出一些用于装饰的子类了。而其子类才是赋有具体装饰效果的装饰产品类。
• ConcreteDecorator是具体的装饰产品类，每一种装饰产品都具有特定的装饰效果。可以通过构造器声明装饰哪种类型的ConcreteComponent，从而对其进行装饰。

装饰器模式为什么需要如此结构？

1. 装饰器模式最核心的功能在于具体的装饰器类可以重写具