为什么需要装饰器模式?
我们要买奶茶,希望加红豆和布丁。考虑如何实现这个对象的构造:
- 把红豆和布丁作为两个成员变量:无法动态的添加成员变量
- 创建一个成员变量表示“添加列表”,添加红豆和布丁作为元素:我们的奶茶需要一些修饰方法与红豆和布丁有关
- 红豆和布丁作为两个独立的类,继承奶茶:如果一杯奶茶既添加了红豆又添加了布丁则无法实现这种效果
可见普通的组合和继承都无法很好的实现我们的要求。
装饰器模式概念
- Component为统一接口,也是装饰类和被装饰类的基本类型。
- ConcreteComponent为具体实现类,也是被装饰类,他本身是个具有一些功能的完整的类。
- Decorator是装饰类,实现了Component接口的同时还在内部维护了一个ConcreteComponent的实例,并可以通过构造函数初始化。而Decorator本身,通常采用默认实现,他的存在仅仅是一个声明:我要生产出一些用于装饰的子类了。而其子类才是赋有具体装饰效果的装饰产品类。
- ConcreteDecorator是具体的装饰产品类,每一种装饰产品都具有特定的装饰效果。可以通过构造器声明装饰哪种类型的ConcreteComponent,从而对其进行装饰。
装饰器模式为什么需要如此结构?
- 装饰器模式最核心的功能在于具体的装饰器类可以重写具