装饰模式（Decorator Pattern）
说明：本文为《设计模式之禅》的阅读笔记，主要总结精华和记录自己的部分理解。代码部分由Kotlin实现。
1. 定义
Attach additional responsibilities to an object dynamically keeping the same interface.Decorators provide a flexible alternative to subclassing for extending functionality.
动态地给一个对象添加一些额外的职责。 就增加功能来说，装饰模式相比生成子类更为灵活。
也有叫“装饰器模式”。
通俗理解：在不改变现有对象结构的前提下，动态的给该对象增加一些额外的职责（功能）。
装饰模式的通用类图如下：
装饰模式通用类图.png
其中有四个角色：
-
Component抽象构件
Component是一个接口或抽象类，是我们定义的最核心的对象，也是最原始的对象。（是我们想要增加额外职责的对象）
注意 在装饰模式中，必然有一个最基本、最核心、最原始的接口或抽象类充当 Component抽象构件。
-
ConcreteComponent具体构件
ConcreteComponent是最核心、最原始、最基本的接口或抽象类（Component）的实现，我们要装饰的就是这个对象。 -
Decorator装饰角色
一般是一个抽象类，实现接口或者抽象方法，在它的属性里必然有一个private变量指向Component抽象构件。
如果只有一个装饰类，则可以没有抽象装饰角色，直接实现具体的装饰角色即可。 -
具体装饰角色
ConcreteDecoratorA和ConcreteDecoratorB是两个具体的装饰类，我们要把你最核心的、最原始的、最基本的东西装饰成其他东西。
下面用kotlin实现一下通用的装饰模式，如代码清单1.
代码清单1 装饰模式通用代码
// 抽象构件
abstract class Component {
abstract fun operate()
}
// 具体构件
class ConcreteComponent : Component() {
// 具体实现
override fun operate() {
println("do something in ConcreteComponent")
}
}
// 抽象装饰者
// 如果只有一个装饰类，则可以没有抽象装饰角色，直接实现具体的装饰角色即可
abstract class Decorator(protected open val component: Component) : Component() {
// 委托给被修饰者执行
override fun operate() {
component.operate()
}
}
// 具体的装饰类
class ConcreteDecorator1(component: Component): Decorator(component) {
// 重写父类的Operation方法
override fun operate() {
this.method1()
super.operate()
}
// 定义自己的修饰方法
private fun method1() {
println("method1 修饰 in ConcreteDecorator1")
}
}
// 具体的装饰类
class ConcreteDecorator2(component: Component): Decorator(component) {
// 重写父类的Operation方法
override fun operate() {
super.operate()
this.method2()
}
// 定义自己的修饰方法
private fun method2() {
println("method2 修饰 in ConcreteDecorator2")
}
}
// 场景类
fun main(args: Array<String>) {
var component: Component = ConcreteComponent()
// 第一次修饰
component = ConcreteDecorator1(component)
// 第二次修饰
component = ConcreteDecorator2(component)
// 修饰后运行
component.operate()
}
运行结果：
method1 修饰 in ConcreteDecorator1
do something in ConcreteComponent
method2 修饰 in ConcreteDecorator2
Process finished with exit code 0
注意 原始方法和装饰方法的执行顺序在具体的装饰类是固定的，可以通过方法重载实现多种执行顺序。
再来看一个实际的例子，如代码清单2：
代码清单2 咖啡机
// 抽象构件-咖啡机
interface CoffeeMachine {
fun makeEspresso()
fun makeDoubleEspresso()
}
// 具体构件-普通咖啡机
class NormalCoffeeMachine: CoffeeMachine {
override fun makeEspresso() {
println("make espresso")
}
override fun makeDoubleEspresso() {
println("make double espresso twice")
}
}
// 装饰类
class EnhancedCoffeeMachine(private val coffeeMachine: CoffeeMachine) : CoffeeMachine by coffeeMachine {
override fun makeDoubleEspresso() {
println("once time")
println("make double espresso")
}
fun makeCoffeeWithMilk() {
coffeeMachine.makeEspresso()
println("add milk")
}
}
// 场景类
fun main(args: Array<String>) {
val normalCoffeeMachine = NormalCoffeeMachine()
val enhancedCoffeeMachine = EnhancedCoffeeMachine(normalCoffeeMachine)
enhancedCoffeeMachine.makeEspresso() // 非重写
enhancedCoffeeMachine.makeDoubleEspresso() // 重写了
enhancedCoffeeMachine.makeCoffeeWithMilk()
}
运行结果：
make espresso
once time
make double espresso
make espresso
add milk
2. 装饰模式的优缺点
2.1 优点
-
装饰类和被装饰类可以独立发展，而不会相互耦合。
Component类无须知道Decorator类，Decorator类是从外部来扩展Component类的功能，而Decorator也不用知道具体的构件。 -
装饰模式是继承关系的一个替代方案。
-
装饰模式可以动态地扩展一个实现类的功能。
2.1 缺点
-
多层的装饰是比较复杂的。
为什么会复杂呢？你想想看，就像剥洋葱一样，你剥到了最后才发现是最里层的装饰出现了问题，想象一下工作量吧，因此，尽量减少装饰类的数量，以便降低系统的复杂度。
装饰模式特点总结
- 装饰模式是继承的有力补充，比继承灵活，在不改变原有对象的情况下，动态的给一个对象扩展功能，即插即用；
- 通过使用不同装饰类及这些装饰类的排列组合，可以实现不同效果；
- 装饰器模式完全遵守开闭原则；
- 装饰模式会增加许多子类，过度使用会增加程序得复杂性。
3. 装饰模式的使用场景
- 需要扩展一个类的功能，或给一个类增加附加功能。
- 需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
- 需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式。
4. 最佳实践
装饰模式是对继承的有力补充。
和使用继承来解决问题相比：
- 用继承解决问题，容易增加很多子类，灵活性差，不易维护。 -> 装饰模式可以替代继承，解决类膨胀问题。
- 继承是静态地给类增加功能 -> 装饰模式是动态增加功能（不想要可以在场景类中不要）
装饰模式非常好的优点：扩展性好
假设，三个继承关系Father、Son、GrandSon三个类，我们需要在Son类上增强一些功能怎么办？我想你会坚决地顶回去！不允许，对了，为什么呢？你增强的功能是修改Son类中的方法吗？增加方法吗？对GrandSon的影响呢？特别是GrandSon 有多个的情况，你会怎么办？这个评估的工作量就够你受的，所以这是不允许的，那还是要解决问题的呀，怎么办？通过建立SonDecorator类来修饰Son，相当于创建了一个新的类，这个对原有程序没有变更，通过扩展很好地完成了这次变更。
附1：思维导图
装饰模式 （Decorator Pattern）.png
