1.引言

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

2.概念与模式

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

装饰模式的实现类关系图为：

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

 

 

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

 

 

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

 

 

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

3.应用实例

一部手机，在其接受到来电的时候，会发出声音来提醒主人。而现在我们需要为该手机添加一项功能，在接收来电的时候，产生震动，而令一部更加高级，不仅发声，而且振动，而且有灯光闪烁。

用装饰模式来解决这个问题的类关系图为：

相关文件为：

Component

 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

Concrete Component

 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

Decorator

 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

Concrete Decorator

 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提到的装饰模式的缺点，你能体会吗？他们所说的小对象我认为是指的具体装饰角色。这是为一个对象动态添加功能所带来的副作用。

   源码下载: