设计模式学习笔记十五:装饰模式(Decorator Pattern)

长平狐 发布于 2013/06/17 12:54
阅读 108
收藏 0

     1.概述

     将表现与逻辑分离,是应用设计的一重要原则,在WEB应用中显得尤为重要,因为用户对界面形式的要求是易变的,并且是非常苛刻的。如果应用逻辑与显示纠缠在一起,就会导致对界面上既是很小的一点改动,都会牵扯到逻辑的变化。在这种情况下,我们可以继承来扩展对象的功能,但是由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展功能的组合)会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致的影响将为最低?这就是装饰模式。

     装饰模式:动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。说白了,就是在不改变对象的前提下,动态的增加其功能,即我们不希望改变原有的类,或采用创建子类的方法来增加功能的时候,这种情况下我们要采用装饰模式。装饰模式的结构图如下:

     

     模式中的参与者如下:
     (1).Component:定义一个对象接口,可以动态添加这些对象的功能;
     (2).ConcreteComponent:定义一个对象,可以为其添加一些功能;
     (3).Decorator:维持一个对Component对象的引用,并定义与Component接口一致的接口;
     (4).ConcreteDecorator:为组件添加功能。
     下面是基本的实现代码:
Code
     调用代码:
Code

     修饰一个对象后,其接口不应该发生变化;否则这个对象不能被原有调用者使用,修饰失去了意义。由此引出了装饰模式最重要的一点,即装饰模者和被装饰者具有相同的接口。说白了,即动态增加的功能不能不应该破坏已有的接口。

     2.实例

      1.数据库操作记录

     当我们执行某种操作时,希望记录日志。日志实际上是与实际操作无关的辅助行为,需要执行的操作也无需知道如何记录日志。我们还希望可以改变记录的方式,如选择在数据库,或者一个XML文件中记录日志,或者不做记录。例如我们在简单工厂中的数据访问,我们现在希望给数据库访问增加操作记录,我们可以通过引进装饰模式完成这个功能,我们增加一个clsAbstractDB的子类LOGSDB,由于接口相同,因此LOGDB可以与其他数据库连接对象一样使用,不同的是,LOGDB并不实际操作数据库,他有一个指向clsAbstractDB的引用,通过这个具体的引用,LOGDB执行实际操作。结构图如下:

     LogDB是这么写的:

 

LOGDB

 

     2.经典的BufferStream-.NET中的装饰模式

     BufferStream是经典的装饰模式。BufferStream的作用是为另一流上的读写操作添加一个缓冲层,从而提高读取和写入性能。其结构如下:

 

     由于在.NET中已经实现了框架,我们只看怎么使用:

 

Code

 

     3.总结

     1.适用性

     在以下情况下应当使用装饰模式:1.需要扩展一个类的功能,或给一个类增加附加责任;2.需要动态地给一个对象增加功能,这些功能可以再动态地撤销;3.需要增加由一些基本功能的排列组合而产生的非常大量的功能,从而使继承关系变得不现实。

     2.实现要点

     让装饰角色还继承抽象构件角色也是装饰模式最大的特点,目的就是给抽象构件增加职责,对外表现为装饰后的构件;

     让装饰角色拥有构件角色实例的目的就是让构件能被多个装饰对象来装饰;

     在具体应用中可以灵活一点,不一定要有抽象构件和装饰角色。但是,装饰对象继承装饰对象并且拥有它实例的两大特点需要体现;

     透明装饰一般通过在基类方法前后进行扩充实现,半透明装饰一般通过新的接口实现。

 

     参考资料:

     大话设计模式

     .net与设计模式

     http://terrylee.cnblogs.com/archive/2006/03/01/340592.html

     http://www.cnblogs.com/lovecherry/archive/2007/10/12/922182.html


原文链接:http://www.cnblogs.com/peida/archive/2008/08/05/1258570.html
加载中
返回顶部
顶部