2.3.1 模式意图:
不需要额外创建子类的情况下，动态的为对象添加功能，并且不会更改类对应的结构。
2.3.2 模式概念:
它属于结构型模式。动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
2.3.3 模式元素:
- 构件抽象（IComponent）
- 构件细节（ChristmasTree）
- 装饰类抽象（ChristmasTreeDecorator）
- 装饰类细节（ChristmasTreeDecorator_Start、ChristmasTreeDecorator_Lights等）
2.3.4 代码示例:
【前期准备】创建一个主题圣诞树（核心），调用展示圣诞树函数
public interface IComponent
{
void Show();
}
public class ChristmasTree : IComponent
{
private readonly string core = "圣诞树";
public virtual void Show()
{
Debug.Log($"展示圣诞节的核心{core}");
}
}
【前期准备】有了新的需求，在
Show函数里添加圣诞星对应的信息
public class ChristmasTree : IComponent
{
private readonly string core = "圣诞树";
public virtual void Show()
{
Debug.Log($"展示圣诞节的核心{core}");
/************************/
Debug.Log("展示圣诞星星");
/************************/
}
}
要添加圣诞彩灯、圣诞礼物或者一些其他的东西，那我们也在原有的Show函数中添加吗？
如果这么做的话显然违反了我们的开闭原则，那么对于这种情况我们应该：把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象，因此，当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择、有顺序的使用装饰功能包装对象了。
A.为ChristmasTree创建装饰器基类
public class ChristmasTreeDecorator : IComponent
{
/// <summary>
/// 上一次圣诞树的状态
/// </summary>
protected IComponent christmasTree = null;
public ChristmasTreeDecorator(IComponent tempChristmasTree)
{
this.christmasTree = tempChristmasTree;
}
public virtual void Show()
{
//上一次圣诞树的状态
this.christmasTree.Show();
}
}
B.有了装饰器的基类后，我们可以在这个基础上创建圣诞星装饰器、彩灯装饰器、礼物装饰器等.
public class ChristmasTreeDecorator_Start : ChristmasTreeDecorator
{
public ChristmasTreeDecorator_Start(IComponent tempChristmasTree) : base(tempChristmasTree) { }
/// <summary>
/// 在上一次的状态基础上进行装饰
/// </summary>
public override void Show()
{
Debug.Log("展示在最上面装饰了一个圣诞星");
//上一次圣诞树的状态
base.christmasTree.Show();
}
}
public class ChristmasTreeDecorator_Lights : ChristmasTreeDecorator
{
public ChristmasTreeDecorator_Lights(IComponent tempChristmasTree) : base(tempChristmasTree) { }
/// <summary>
/// 在上一次的状态基础上进行装饰
/// </summary>
public override void Show()
{
//上一次圣诞树的状态
base.christmasTree.Show();
Debug.Log("展示在最下面装饰了一个圣诞彩灯");
}
}
public class ChristmasTreeDecorator_Gift : ChristmasTreeDecorator
{
public ChristmasTreeDecorator_Gift(IComponent tempChristmasTree) : base(tempChristmasTree) { }
/// <summary>
/// 在上一次的状态基础上进行装饰
/// </summary>
public override void Show()
{
//上一次圣诞树的状态
base.christmasTree.Show();
Debug.Log("展示在最下面放了一些礼物");
}
}
C.然后我们的运行代码可以这么用
public void Function_One()
{
ChristmasTree christmasTree = new ChristmasTree();
ChristmasTreeDecorator_Lights tree_Lights = new ChristmasTreeDecorator_Lights(christmasTree);
ChristmasTreeDecorator_Gift tree_Gift = new ChristmasTreeDecorator_Gift(tree_Lights);
ChristmasTreeDecorator_Start tree_Start = new ChristmasTreeDecorator_Start(tree_Gift);
tree_Start.Show();
}
打印信息
这样我们可以有效地把类的核心职责和装饰功能区分开了，而且可以去除相关类中重复的装饰逻辑
对于执行代码我们可以继续重构优化
D.既然所有的装饰器都是继承自装饰器基类，我们可以这么写
public void Function_Two()
{
ChristmasTree christmasTree = new ChristmasTree();
ChristmasTreeDecorator tree_Lights = new ChristmasTreeDecorator_Lights(christmasTree);
ChristmasTreeDecorator tree_Gift = new ChristmasTreeDecorator_Gift(tree_Lights);
ChristmasTreeDecorator tree_Start = new ChristmasTreeDecorator_Start(tree_Gift);
tree_Start.Show();
}
E.装饰器基类又是继承自
IComponent，又可以这么写
public void Function_Three()
{
ChristmasTree christmasTree = new ChristmasTree();
IComponent tree_Lights = new ChristmasTreeDecorator_Lights(christmasTree);
IComponent tree_Gift = new ChristmasTreeDecorator_Gift(tree_Lights);
IComponent tree_Start = new ChristmasTreeDecorator_Start(tree_Gift);
tree_Start.Show();
}
F.所有的声明都是
IComponent，最后这样写
public void Function_Four()
{
IComponent christmasTree = new ChristmasTree();
christmasTree = new ChristmasTreeDecorator_Lights(christmasTree);
christmasTree = new ChristmasTreeDecorator_Gift(christmasTree);
christmasTree = new ChristmasTreeDecorator_Start(christmasTree);
christmasTree.Show();
}
2.3.5 写法对比:
略
2.3.6 模式分析:
装饰类和被装饰类彼此独立，互不干扰，又不失去彼此间的关联。装饰模式是继承的一个替代模式，单耦合性更低。
不足之处
随着多层装饰的深度增加，出错几率增大，排错也变的复杂，代码量增多。
2.3.7 应用场景:
例如我们已经写好一个相应的战斗模块，但是在进入之前或者进入之后添加一些，输出日志、数据监测、数据收集埋点触发之类的功能，其实这些都可以用这个装饰器模式
2.3.8 小结:
把装饰器模式这种思想发扬光大的另一种编程方式就是面向切面编程（AOP），既没有更改写好的模块，又添加了一些需要的辅助措施，注意是辅助措施，如果是核心玩法之类的改动，笔者还是建议不要用装饰器模式了。
