C++设计模式之装饰模式

1、o+设计模式之装饰模式这篇文章主要介绍了 c+设计模式之装饰模式，装饰模式能够实现动态的为对彖添加功能，是 从一个对象外部来给对象添加功能，需要的朋友可以参考下>刖百在实际开发时，你有没有碰到过这种问题；开发一个类，封装了一个对象的核心操作，而这 些操作就是客户使用该类时都会去调用的操作；而有一些非核心的操作，可能会使用，也可 能不会使用；现在该怎么办呢？1将这些非核心的操作全部放到类屮，这样，一个类就包含了很多核心的操作和一些看似有 关，但是又无关的操作；这就会使核心类发生“爆炸”的现象，从而使核心类失去了一定的 价值，也使使用核心类的客户在核心操作和非核心操作屮挣扎；2. 使用继承来

2、扩展核心类，需要使用核心类时，直接建立核心类对象；当需要使用核心类扩 展类吋，就建立核心类扩展类对象；这样貌似是一种很有效的方法；但是由于继承为类型引 入的静态特质，使得这种扩展方式缺乏灵活性；同时，又掉入了另一个陷阱，随着扩展功能 的增多，子类也会增多，各种子类的组合，就会导致类的膨胀，最后，就会被淹没在类的海 洋；此时，也不用我多说，你是不是想起了桥接模式，桥接模式就是为了适应多个维度的变 化而发生子类“爆炸”的情况，但是，桥接模式是为了适应抽象和实现的不同变化，并不适 用于我这里说的。那如何是好，这就要说到今天总结的装饰模式了。什么是装饰模式？在gof的设计模式:对复用面向对象软件的基础

3、一书中对装饰模式是这样说的：动态地 给一个对象添加一些额外的职责。就增加功能来说，decorator模式相比生成子类更为灵活。 装饰模式能够实现动态的为对象添加功能，是从一个对象外部来给对象添加功能。通常给对 象添加功能，要么直接修改对象添加相应的功能，要么派生对应的子类来扩展，抑或是使用 对象组合的方式。显然，直接修改对应的类这种方式并不可取。在面向对象的设计屮，而我 们也应该尽量使用对象组合，而不是对象继承來扩展和复用功能。装饰器模式就是基于对象 组合的方式，可以很灵活的给对象添加所需要的功能。装饰器模式的本质就是动态组合。动 态是手段，组合才是目的。总之，装饰模式是通过把复杂的功能简单化

4、，分散化，然后再运 行期i'可，根据需要来动态组合的这样一个模式。它使得我们可以给某个对彖而不是整个类添 加一些功能。uml类图component:定义一个对象接口，可以给这些对象动态地添加职责；concretecomponent:定义一个具体的 component,继承自 concreatecomponent,重写了 component类的庞函数；decorator:维持一个指向component对象的指针，该指针指向需要被装饰的对象；并定义一 个与component接口一致的接口；concretedecorator:向组件添加职责。代码实现：复制代码代码如下：/* filename

5、 : decoratorpatterndemo* author: jelly young* date: 2011/19* description : more information, please go to */#inelude <iostream>using namespace std;class comp orientpublic:virtual void operation() = 0;class con cretecomp on ent: public comp on entpublic:void operation!)cout«hl am no decora

6、tored concretecomponentn«endl;class decorator: public componentpublic:decorator(component *pcomponent): m_pcomponentobj(pcomponent) void operation()if (m_pcomponentobj != null)m_pcomp on entobj->operati on();protected:component *m_pcomponentobj;class concretedecoratora : public decoratorpubl

7、ic:concretedecoratora(component *pdecorator): decorator(pdecorator)void operation)addedbehavior();decorator:operation();void addedbehavior() cout«"this is added behavior a.h«endl;class concretedecoratorb : public decorator public:concretedecoratorb(component *pdecorator): decorator(pd

8、ecorator)void operation)addedbehavior();decorator:operatio n();void addedbehavior()cout«hthis is added behavior b.u«endl;int main()comp on ent *pcomp onen tobj = new con cretecomp on ent();decorator *pdecoratoraojb = new concretedecoratora(pcomponentobj); pdecoratoraojb->operati on(); c

9、out«h=n«e ndl;decorator *pdecoratorbojb = new concretedecoratorb(pcomponentobj); pdecoratorbojb->operati on(); cout«h="«e ndl;decorator *pdecoratorbaojb = new concretedecoratorb(pdecoratoraojb); pdecoratorbaojb->operation(); cout«,=,«e ndl;delete pdecoratorba

10、ojb; pdecoratorbaojb = null;delete pdecoratorbojb; pdecoratorbojb = null;delete pdecoratoraojb; pdecoratoraojb = null; delete pcomponentobj; pcomponentobj = null;使用场合1. 在不影响其他对象的情况下，以动态的，透明的方式给单个对象添加职责；2处理那些可以撤销的职责；3. 当不能采用生成子类的方法进行扩充时。一种情况是，可能存在大量独立的扩展，为支持 每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义 被

11、隐藏，或类定义不能用于生成子类。注意事项1接口的一致性；装饰对彖的接口必须与它所装饰的component的接口是一致的，因此，所 有的concretedecorator类必须有一个公共的父类；这样对于用户来说，就是统一的接口；2. 省略抽象的decorator类；当仅需要添加一个职责时，没有必要定义抽象decorator类。因 为我们常常要处理，现存的类层次结构而不是设计一个新系统，这时可以把decorator向 component转发请求的职贵合并到concretedecorator中；3. 保持component类的简单性；为了保证接口的一致性，组件和装饰必须要有一个公共的 compone

12、nt类，所以保持这个component类的简单性是非常重要的，所以，这个component 类应该集中于定义接口而不是存储数据。对数据表示的定义应延迟到子类中，否则 component类会变得过于复杂和臃肿，因而难以大量使用。赋予component类太多的功能, 也使得具体的子类有一些它们它们不需要的功能大大增大；实现要点1. component类在decorator模式中充当抽象接口的角色，不应该去实现具体的行为。而且 decorator类对于component类应该透明，换言之component类无需知道decorator类， decorator类是从外部來扩展component类的功能；

13、2. decorator类在接口上表现为“is-a” component的继承关系，即decorator类继承了 component类所具有的接口。但在实现上又表现为“hasa” component的组合关系，即 decorator类乂使用了另外一个component类。我们可以使用一个或者多个decorator对彖 来"装饰"一个component对象，且装饰后的对象仍然是一个component对象；3. decortor模式并非解决“多子类衍生的多继承”问题，decorator模式的应用要点在于解决“主体类在多个方向上的扩展功能” 一一是为“装饰”的含义；4. 对于de

14、corator模式在实际屮的运用可以很灵活。如果只有一个concretecomponent类而 没有抽彖的component类，那么decorator类可以是concretecomponent的一个子类。如果 只有一一个concretedecorator类，那么就没有必要建立一个单独的decorator类，而可以把 decorator 和 concretedecorator 的责任合并成一个类。5. decorator模式的优点是捉供了比继承更加灵活的扩展，通过使用不同的具体装饰类以及 这些装饰类的排列组合，可以创造出很多不同行为的组合；6由于使用装饰模式，可以比使用继承关系需要较少数目的类。

15、使用较少的类，当然使设计 比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多 的对象会使得查错变得困难，特別是这些对象看上去都很相像。与桥接模式的区别z前总结了 c+设计模式一一桥接模式；你会发现，二者都是为了防止过度的继承，从而造 成子类泛滥的情况。那么二者之间的主要区别是什么呢？桥接模式的定义是将抽象化与实现 化分离（用组合的方式而不是继承的方式），使得两者可以独立变化。可以减少派生类的增 长。如果光从这一点來看的话，和装饰者差不多，但两者还是有一些比较重要的区别： 1桥接模式中所说的分离，其实是指将结构与实现分离（当结构和实现有可能发生变化时） 或属性与基于

16、属性的行为进行分离；而装饰者只是对基于属性的行为进行封闭成独立的类, 从而达到对其进行装饰，也就是扩展。比如：异常类和异常处理类之间就可以使用桥接模式 来实现完成，而不能使用装饰模式来进行设计；如果对于界常的处理需要进行扩展吋，我们 又可以对异常处理类添加decorator,从而添加处理的装饰，达到异常处理的扩展，这就是 一个桥接模式与装饰模式的搭配；2.桥接中的行为是横向的行为，行为彼此z间无关联，注意这里的行为z间是没有关联的， 就比如异常和异常处理z间是没有行为关联的一样；而装饰者模式中的行为具有可叠加性, 其表现出来的结果是一个整体，一个各个行为组合后的一个结果。总结装饰模式重点在装饰，对核心功能的装饰作用；将继承屮对子类的扩展转化为功能类的组合, 从而将