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

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

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

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

 

 

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

 

 

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

 

 

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


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

Component

Concrete Component


Decorator

Concrete Decorator

客户端调用

运行结果:

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

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

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

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

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


五、透明和半透明
 
 

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

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

posted @ 2006-08-27 02:01 Robin Zhang 阅读(...) 评论(...) 编辑 收藏