[toc]
设计模式03-装饰者设计模式
主要来源Head First设计模式（书）
第5个设计原则（开放-关闭原则）
类应该对扩展开放，对修改关闭。
第1.2.3设计原则(GitHub地址)
第4个设计模式(GitHub地址)
我们的目标时允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。如果实现这样的目标有什么好处呢？这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。
定义
动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
特征
- 装饰者和被装饰者有相同的超类型
- 你可以用一个或多个装饰者包装一个对象
- 既然装饰者和被装饰者有相同的超类型，所以在任何需要原始对象(被包装的)场合，可以用装饰过的对象替代它。
- 装饰者可以在所委托被装饰者的行为之前与／或之后，加上自己的行为，以达到特定的目的。
- 对象可以在任何时候被装饰。所以可以在运行时动态的、不限量的用你喜欢的装饰者来装饰对象
缺点->可以看java.io类
造成设计中有大量的小类，从而导致理解不太容易。
案例分析
英雄联盟
建立超类英雄
abstract class 英雄 {
protected var mName = "未知英雄"
fun getName(): String {
return mName
}
/**
* 英雄花费价格
*/
abstract fun cost(): Int
}
建立具体子类
提莫队长
class 提莫队长 : 英雄() {
init {
mName = "提莫队长"
}
override fun cost(): Int {
Log.d("123===", "买提莫队长花费100")
return 100
}
}
蛮王
class 蛮王 : 英雄() {
init {
mName = "蛮王"
}
override fun cost(): Int {
Log.d("123===", "买蛮王花费200")
return 200
}
}
建立装饰者类
abstract class 技能(val 子英雄: 英雄) : 英雄() {
init {
子英雄.getName()
}
abstract fun 学习技能(): String
}
建立具体装饰者
技能Q
class 技能Q(子英雄: 英雄) : 技能(子英雄) {
init {
mName = 子英雄.getName() + ",学习技能Q"
}
override fun 学习技能(): String {
return "学习技能Q"
}
override fun cost(): Int {
val cost = 子英雄.cost() + 1
Log.d("123===", "学习Q技能花费1")
return cost
}
}
技能R
class 技能R(子英雄: 英雄) : 技能(子英雄) {
init {
mName = 子英雄.getName() + ",学习技能R"
}
override fun 学习技能(): String {
return "学习技能R"
}
override fun cost(): Int {
val cost = 子英雄.cost() + 2
Log.d("123===", "学习R技能花费2")
return cost
}
}
使用
var a: 英雄 = 提莫队长()
a = 技能Q(a)
a = 技能R(a)
Log.d("123===", "流程：${a.getName()}")
Log.d("123===", "一共花费了${a.cost()}")
结果
流程：提莫队长,学习技能Q,学习技能R
买提莫队长花费100
学习Q技能花费1
学习R技能花费2
一共花费了103
UML
装饰者设计模式
