C# Design Patterns (3) - Decorator

核心提示： 图 3示例 02_Steak.aspx.cs 的执行结果，扩展功能时，C# Design Patterns (3) - Decorator(6)，主菜和副菜可任意混合搭配使用原理与本帖之前提过的相同，将来店里若要推出 羊排、鱼排、…等新的主菜 (被装饰者) 时，在某些实际应用

图 3　示例 02_Steak.aspx.cs 的执行结果。扩展功能时，主菜和副菜可任意混合搭配使用

原理与本帖之前提过的相同，将来店里若要推出 羊排、鱼排、…等新的主菜 (被装饰者) 时，只要增加一个类，去继承 Meal 这个抽象的基类即可；若要推出新的副菜 (装饰者) 也一样，只要增加一个类，去继承 CondimentDecorator 抽象类即可。我们透过这个重要的 CondimentDecorator 抽象类，实现 UML 的 Aggregation (聚合) 观念，以「装饰模式」取代传统「继承」的做法，也同时降低了「主菜」、「副菜」这两种类之间的耦合度。

这个 CondimentDecorator 抽象类的作用，还可将未来所有种类的副菜，一些「共同的」行为或职责写在里面。而且，它还可用来区分哪些类是主菜，哪些类是副菜，因为主菜、副菜都是继承自 Meal 这个最顶层的基类，若没有这个 CondimentDecorator 抽象类，将来 Class Diagram 变得很复杂时，会不易分辨某个类是主菜或副菜。

此外，也因为主菜 (被装饰者)、副菜 (装饰者) 都是继承自 Meal 这个最顶层的基类，所以客户端程序 (Page_Load) 在引用他们的对象时，把 new 出来的主菜实例、new 出来的副菜实例，再抛入其他副菜实例的构造函数中，也会相容、不会发生错误，在相互引用和「运行」时期的「动态」扩展上，变得很有弹性。

最后补充一点，Decorator 模式中，装饰者类对象，在组合时的「顺序」亦很重要。本帖图 1 中，ConcreteDecoratorA、ConcreteDecoratorB、ConcreteDecoratorC、... 等具体装饰者，在动态添加和组合时，在某些实际应用中必须依照一定的顺序，若顺序相反可能会导致程序执行结果不合理，但本帖所提供的几个例子中并不需要考虑到这点。