设计模式之装饰模式篇(Decorator)

1.引言
如果我们对自己所居住的房间不满意的时候，我们往往是通过装修的方式来使我们的房间变的漂亮起来。而不是重新建一个房间。而且经过装修的屋子仍让是原来的屋子，本质不会变，但它的确变漂亮了，满足了我们的美的需求。从投入来看，装修比重新建设显然要便宜的多! 在软件设计里面，此类情形的设计既可以采用装饰模式(Decorator)来完成。
2.概念与模式

装饰模式（Decorator）也叫包装器模式（Wrapper）。GOF在《设计模式》一书中给出的定义为：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
装饰模式的实现类关系图为：

1)        抽象构件角色（Component）：定义一个抽象接口，以规范准备接收附加责任的对象。

 

 

2)        具体构件角色(Concrete Component)：这是被装饰者，定义一个将要被装饰增加功能的类。

 

 

3)        装饰角色(Decorator)：持有一个构件对象的实例，并定义了抽象构件定义的接口。

 

 

4)        具体装饰角色(Concrete Decorator)：负责给构件添加增加的功能。

3.应用实例
一部手机，在其接受到来电的时候，会发出声音来提醒主人。而现在我们需要为该手机添加一项功能，在接收来电的时候，产生震动，而令一部更加高级，不仅发声，而且振动，而且有灯光闪烁。
用装饰模式来解决这个问题的类关系图为：
相关文件为：

 1using System;
 2using System.Collections.Generic;
 3using System.Text;
 4
 5namespace Decorator
 6{
 7    public interface IPhone
 8    {
 9        /// <summary>
10        /// 接收电话
11        /// </summary>
12        void ReceiveCall();
13    }
14}
15

 1using System;
 2using System.Collections.Generic;
 3using System.Text;
 4
 5namespace Decorator
 6{
 7    public class BasePhone:IPhone
 8    {
 9        public void ReceiveCall()
10        {
11            Console.WriteLine("Ring..");
12        }
13    }
14}
15

 1using System;
 2using System.Collections.Generic;
 3using System.Text;
 4
 5namespace Decorator
 6{
 7    public abstract class PhoneDecorator:IPhone
 8    {
 9        IPhone phone = null;
10        public PhoneDecorator(IPhone phone)
11        {
12            if (phone != null)
13            {
14                this.phone = phone;
15            }
16            else
17            {
18                this.phone = new BasePhone();
19            }
20        }
21        public virtual void ReceiveCall()
22        {
23            phone.ReceiveCall();
24        }
25    }
26}
27

 1using System;
 2using System.Collections.Generic;
 3using System.Text;
 4
 5namespace Decorator
 6{
 7    public class JarPhone:PhoneDecorator
 8    {
 9        public JarPhone(BasePhone phone)
10            : base(phone)
11        {
12        }
13        public override void ReceiveCall()
14        {
15            base.ReceiveCall();
16            Console.WriteLine("Jar");
17        }
18    }
19}
20
21
22
23using System;
24using System.Collections.Generic;
25using System.Text;
26
27namespace Decorator
28{
29    public class ComplexPhone:PhoneDecorator
30    {
31        public ComplexPhone(JarPhone phone)
32            : base(phone)
33        {
34        }
35        public override void ReceiveCall()
36        {
37            base.ReceiveCall();
38            Console.WriteLine("Wink");
39        }
40    }
41}
42

 1using System;
 2using System.Collections.Generic;
 3using System.Text;
 4
 5namespace Decorator
 6{
 7    class Program
 8    {
 9        static void Main(string[] args)
10        {
11            BasePhone phone = new BasePhone();
12            phone.ReceiveCall();
13            Console.WriteLine("---------------------");
14            JarPhone p2 = new JarPhone(phone);
15            p2.ReceiveCall();
16            Console.WriteLine("---------------------");
17            ComplexPhone p3 = new ComplexPhone(p2);           
18            p3.ReceiveCall();
19            Console.Read();
20        }
21    }
22}
23

运行结果：

四、应用环境 
       GOF书中给出了以下使用情况： 
1)        在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。 

2)        处理那些可以撤消的职责。  

3)        当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。  

来分析下手机的使用是属于哪种情况。首先实现了比静态继承更加灵活的方式，动态的增加功能。试想为手机的所有实现类通过继承来增加一个功能，意味着要添加不少的功能类似的子类，这明显是不太合适的。 

而且，这就避免了高层的类具有太多的特征。 

五、透明和半透明  

       对于面向接口编程，应该尽量使客户程序不知道具体的类型，而应该对一个接口操作。这样就要求装饰角色和具体装饰角色要满足Liskov替换原则。

六、其它 采用Decorator模式进行系统设计往往会产生许多看上去类似的小对象，这些对象仅仅在他们相互连接的方式上有所不同，而不是它们的类或是它们的属性值有所不同。尽管对于那些了解这些系统的人来说，很容易对它们进行定制，但是很难学习这些系统，排错也很困难。这是GOF提到的装饰模式的缺点，你能体会吗？他们所说的小对象我认为是指的具体装饰角色。这是为一个对象动态添加功能所带来的副作用。