C# Design Patterns (3) - Decorator

核心提示： 上方图 1 的 Class Diagram，以及「Shell (壳)」示例中，C# Design Patterns (3) - Decorator(3)，ConcreteComponent 即为此一模式中的「被装饰者」，而 Decorator 抽象类及其具体子类 ConcreteDecor

上方图 1 的 Class Diagram，以及「Shell (壳)」示例中，ConcreteComponent 即为此一模式中的「被装饰者」，而 Decorator 抽象类及其具体子类 ConcreteDecoratorA、ConcreteDecoratorB 即为「装饰者」。此外，这个模式中最核心的就是 Decorator 这个抽象类，它用一个以父类 Component 声明的变量 component，实现 UML 中的 Aggregation (聚合，有的博文也统称为「组合」或「合成」)，亦即为指向 Component 对象的指针，达到我们前述 - 「动态」进行扩展的目的。

至于其设计的原理，以下我引用博客园一位前辈 Justin 两年前所写博文的一段内容 [1]，这段是我认为对 Decorator 模式极优的说明。读者亦可搭配参考上方代码里我添加的注释，稍后我会再补充说明。

--------------------------------------------------------

Decorator 是装饰者模式里非常特殊的一个类，它既继承于 Component【IS A关系】，又维护一个指向 Component 实例的引用【HAS A关系】，换个角度来说，Decorator 跟 Component 之间，既有动态组合关系，又有静态继承关系，WHY? 这里为什么要这么来设计？上面我们说过，组合的好处是可以在运行时给对象增加职责，Decorator【HAS A】Component 的目的，是让 ConcreteDecorator 可以在运行时动态地给 ConcreteComponent 增加职责，这一点相对来说还比较好理解；那么 Decorator 继承于 Component 的目的是什么？在这里继承的目的只有一个，那就是可以统一「装饰者」和「被装饰者」的接口，换个角度来说，不管是 ConcretComponent 还是 ConcreteDecorator，它们都是最顶层 Component 基类，用户代码可以把它们统一看作 Component 来处理，这样带来的更深一层好处就是，「装饰者」对象，对「被装饰者」对象的功能职责扩展，对用户代码来说是完全透明的，因为用户代码引用的都是 Component，所以就不会因为「被装饰者」对象在被装饰后，引用它的用户代码发生错误，实际上不会有任何影响，因为装饰前后，用户代码引用的都是 Component 类型的对象，这真是太完美了！「装饰模式」通过继承，实现统一了「装饰者」和「被装饰者」的接口，通过组合获得了在运行时动态扩展「被装饰者」对象的能力。