现在的位置: 首页 > 自动控制 > 工业·编程 > 正文

C++设计模式(10):装饰模式

2015-03-24 17:21 工业·编程 ⁄ 共 4913字 ⁄ 字号 评论 2 条

    在实际开发时,你有没有碰到过这种问题;开发一个类,封装了一个对象的核心操作,而这些操作就是客户使用该类时都会去调用的操作;而有一些非核心的操作,可能会使用,也可能不会使用;现在该怎么办呢?

  1. 将这些非核心的操作全部放到类中,这样,一个类就包含了很多核心的操作和一些看似有关,但是又无关的操作;这就会使核心类发生“爆炸”的现象,从而使核心类失去了一定的价值,也使使用核心类的客户在核心操作和非核心操作中挣扎;
  2. 使用继承来扩展核心类,需要使用核心类时,直接建立核心类对象;当需要使用核心类扩展类时,就建立核心类扩展类对象;这样貌似是一种很有效的方法;但是由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性;同时,又掉入了另一个陷阱,随着扩展功能的增多,子类也会增多,各种子类的组合,就会导致类的膨胀,最后,就会被淹没在类的海洋;此时,也不用我多说,你是不是想起了桥接模式,桥接模式就是为了适应多个维度的变化而发生子类“爆炸”的情况,但是,桥接模式是为了适应抽象和实现的不同变化,并不适用于我这里说的。那如何是好,这就要说到今天总结的装饰模式了。

什么是装饰模式?

在GOF的《设计模式:可复用面向对象软件的基础》一书中对装饰模式是这样说的:动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。

装饰模式能够实现动态的为对象添加功能,是从一个对象外部来给对象添加功能。通常给对象添加功能,要么直接修改对象添加相应的功能,要么派生对应的子类来扩展,抑或是使用对象组合的方式。显然,直接修改对应的类这种方式并不可取。在面向对象的设计中,而我们也应该尽量使用对象组合,而不是对象继承来扩展和复用功能。装饰器模式就是基于对象组合的方式,可以很灵活的给对象添加所需要的功能。装饰器模式的本质就是动态组合。动态是手段,组合才是目的。总之,装饰模式是通过把复杂的功能简单化,分散化,然后再运行期间,根据需要来动态组合的这样一个模式。它使得我们可以给某个对象而不是整个类添加一些功能。

UML类图

Component:定义一个对象接口,可以给这些对象动态地添加职责;

ConcreteComponent:定义一个具体的Component,继承自Component,重写了Component类的虚函数;

Decorator:维持一个指向Component对象的指针,该指针指向需要被装饰的对象;并定义一个与Component接口一致的接口;

ConcreteDecorator:向组件添加职责。

代码实现

/*
** FileName     : DecoratorPatternDemo
** Author       : Jelly Young
** Date         : 2013/12/19
** Description  : More information, please go to http://www.jellythink.com
*/
#include <iostream>
using namespace std;
class Component
{
public:
     virtual void Operation() = 0;
};
class ConcreteComponent : public Component
{
public:
     void Operation()
     {
          cout<<"I am no decoratored ConcreteComponent"<<endl;
     }
};
class Decorator : public Component
{
public:
     Decorator(Component *pComponent) : m_pComponentObj(pComponent) {}
     void Operation()
     {
          if (m_pComponentObj != NULL)
          {
               m_pComponentObj->Operation();
          }
     }
protected:
     Component *m_pComponentObj;
};
class ConcreteDecoratorA : public Decorator
{
public:
     ConcreteDecoratorA(Component *pDecorator) : Decorator(pDecorator){}
     void Operation()
     {
          AddedBehavior();
          Decorator::Operation();
     }
     void  AddedBehavior()
     {
          cout<<"This is added behavior A."<<endl;
     }
};
class ConcreteDecoratorB : public Decorator
{
public:
     ConcreteDecoratorB(Component *pDecorator) : Decorator(pDecorator){}
     void Operation()
     {
          AddedBehavior();
          Decorator::Operation();
     }
     void  AddedBehavior()
     {
          cout<<"This is added behavior B."<<endl;
     }
};
int main()
{
     Component *pComponentObj = new ConcreteComponent();
     Decorator *pDecoratorAOjb = new ConcreteDecoratorA(pComponentObj);
     pDecoratorAOjb->Operation();
     cout<<"============================================="<<endl;
     Decorator *pDecoratorBOjb = new ConcreteDecoratorB(pComponentObj);
     pDecoratorBOjb->Operation();
     cout<<"============================================="<<endl;
     Decorator *pDecoratorBAOjb = new ConcreteDecoratorB(pDecoratorAOjb);
     pDecoratorBAOjb->Operation();
     cout<<"============================================="<<endl;
     delete pDecoratorBAOjb;
     pDecoratorBAOjb = NULL;
     delete pDecoratorBOjb;
     pDecoratorBOjb = NULL;
     delete pDecoratorAOjb;
     pDecoratorAOjb = NULL;
     delete pComponentObj;
     pComponentObj = NULL;
}

使用场合

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

注意事项

  1. 接口的一致性;装饰对象的接口必须与它所装饰的Component的接口是一致的,因此,所有的ConcreteDecorator类必须有一个公共的父类;这样对于用户来说,就是统一的接口;
  2. 省略抽象的Decorator类;当仅需要添加一个职责时,没有必要定义抽象Decorator类。因为我们常常要处理,现存的类层次结构而不是设计一个新系统,这时可以把Decorator向Component转发请求的职责合并到ConcreteDecorator中;
  3. 保持Component类的简单性;为了保证接口的一致性,组件和装饰必须要有一个公共的Component类,所以保持这个Component类的简单性是非常重要的,所以,这个Component类应该集中于定义接口而不是存储数据。对数据表示的定义应延迟到子类中,否则Component类会变得过于复杂和臃肿,因而难以大量使用。赋予Component类太多的功能,也使得具体的子类有一些它们它们不需要的功能大大增大;

实现要点

  1. Component类在Decorator模式中充当抽象接口的角色,不应该去实现具体的行为。而且Decorator类对于Component类应该透明,换言之Component类无需知道Decorator类,Decorator类是从外部来扩展Component类的功能;
  2. Decorator类在接口上表现为“is-a”Component的继承关系,即Decorator类继承了Component类所具有的接口。但在实现上又表现为“has-a”Component的组合关系,即Decorator类又使用了另外一个Component类。我们可以使用一个或者多个Decorator对象来“装饰”一个Component对象,且装饰后的对象仍然是一个Component对象;
  3. Decortor模式并非解决“多子类衍生的多继承”问题,Decorator模式的应用要点在于解决“主体类在多个方向上的扩展功能”——是为“装饰”的含义;
  4. 对于Decorator模式在实际中的运用可以很灵活。如果只有一个ConcreteComponent类而没有抽象的Component类,那么Decorator类可以是ConcreteComponent的一个子类。如果只有一个ConcreteDecorator类,那么就没有必要建立一个单独的Decorator类,而可以把Decorator和ConcreteDecorator的责任合并成一个类。
  5. Decorator模式的优点是提供了比继承更加灵活的扩展,通过使用不同的具体装饰类以及这些装饰类的排列组合,可以创造出很多不同行为的组合;
  6. 由于使用装饰模式,可以比使用继承关系需要较少数目的类。使用较少的类,当然使设计比较易于进行。但是,在另一方面,使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难,特别是这些对象看上去都很相像。

与桥接模式的区别

之前总结了C++设计模式(8):桥接模式;你会发现,二者都是为了防止过度的继承,从而造成子类泛滥的情况。那么二者之间的主要区别是什么呢?桥接模式的定义是将抽象化与实现化分离(用组合的方式而不是继承的方式),使得两者可以独立变化。可以减少派生类的增长。如果光从这一点来看的话,和装饰者差不多,但两者还是有一些比较重要的区别:

  1. 桥接模式中所说的分离,其实是指将结构与实现分离(当结构和实现有可能发生变化时)或属性与基于属性的行为进行分离;而装饰者只是对基于属性的行为进行封闭成独立的类,从而达到对其进行装饰,也就是扩展。比如:异常类和异常处理类之间就可以使用桥接模式来实现完成,而不能使用装饰模式来进行设计;如果对于异常的处理需要进行扩展时,我们又可以对异常处理类添加Decorator,从而添加处理的装饰,达到异常处理的扩展,这就是一个桥接模式与装饰模式的搭配;
  2. 桥接中的行为是横向的行为,行为彼此之间无关联,注意这里的行为之间是没有关联的,就比如异常和异常处理之间是没有行为关联的一样;而装饰者模式中的行为具有可叠加性,其表现出来的结果是一个整体,一个各个行为组合后的一个结果。

总结

装饰模式重点在装饰,对核心功能的装饰作用;将继承中对子类的扩展转化为功能类的组合,从而将需要对子类的扩展转嫁给用户去进行调用组合,用户如何组合由用户去决定。我在学习装饰模式时,就是重点分析了“装饰”这个词,我们都知道,装饰是在一个核心功能上添加一些附属功能,从而让核心功能发挥更大的作用,但是最终它的核心功能是不能丢失的。这就好比我们进行windows shell开发时,我们是对windows的这层壳进行了功能的装饰,从而实现了我们需要的一些装饰功能,但是最终的功能还是由windows shell去完成。这就好比,我们的装饰就是给核心功能添加了一层外衣,让它看起来更漂亮和完美。

雷哥就要走了,且行且珍重!

作者:jellythink   2013年12月21日 于大连,东软。

目前有 2 条留言    访客:0 条, 博主:0 条 ,引用: 2 条

    外部的引用: 2 条

    • C++设计模式(13):代理模式 | 求索阁
    • 设计模式(七)装饰器模式Decorator(结构型) | 求索阁

    给我留言

    留言无头像?