4 装饰者模式

装饰者模式(Decorator)：动态地将职责附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。

UML如下：

按照《大话》的解释：Component定义了一个对象接口（超类型），可以给这些对象动态地添加职责。ConcreteComponent是一个具体的对象，接下来的实例代码主要给这个对象添加职责。Decorator，装饰抽象类，继承了Component，从外类来扩展Component类的功能。但对于Component来说，无需知道Decorator的存在，ConcreteComponent是具体的装饰对象，起到给Component添加职责的功能。

具体代码如下：

 1 public abstract class Component
 2     {
 3         public abstract void Operate();
 4     }
 5     public abstract class Decorator : Component
 6     {
 7         Component c;
 8         public Decorator(Component cc)
 9         {
10             c = cc;
11         }
12 
13         public override void Operate()
14         {
15             c.Operate();
16         }
17 
18     }
19     public class ConcreteComponent : Component
20     {
21         public override void Operate()
22         {
23             Console.Write("ConcreteComponent");
24         }
25     }
26     public class ConcreteDecoratorA : Decorator
27     {
28         public ConcreteDecoratorA(Component c) : base(c) { }
29         public override void Operate()
30         {
31             base.Operate();
32             Console.Write("+ConcreteDecoratorA");
33         }
34     }
35 
36     public class ConcreteDecoratorB : Decorator
37     {
38         public ConcreteDecoratorB(Component c) : base(c) { }
39 
40         public override void Operate()
41         {
42             base.Operate();
43             Console.Write("+ConcreteDecoratorB");
44         }
45     }

调用代码：

1             Component c = new ConcreteComponent();
2             c = new ConcreteDecoratorB(c);
3             c = new ConcreteDecoratorA(c);
4             c.Operate();

具体装饰对象A和B的调用次序和个数可以任意组合，在这儿便可以体会到装饰者模式的极大灵活性。

但这种设计方案在有些场合会导致装饰者类过多从来带来维护上的困难，实际应用中要注意这一点了。

目前，始终无法很好地理解这种方法，先记录这么点，日后有深化了再来补充吧。