设计模式——装饰模式（Decorator）

要想正确理解设计模式，首先必须明确它是为了解决什么问题而提出来的。

设计模式学习笔记

——Shulin

转载请注明出处：http://blog.csdn.net/zhshulin

1、概念

        装饰模式又名包装(Wrapper)模式。装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。

        但是纯粹的装饰模式很难找到，大多数的装饰模式的实现都是“半透明”的，而不是完全透明的。换言之，允许装饰模式改变接口，增加新的方法。半透明的装饰模式是介于装饰模式和适配器模式之间的。适配器模式的用意是改变所考虑的类的接口，也可以通过改写一个或几个方法，或增加新的方法来增强或改变所考虑的类的功能。

大多数的装饰模式实际上是半透明的装饰模式，这样的装饰模式也称做半装饰、半适配器模式。

2、针对的问题

        动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。不改变接口的前提下，增强所考虑的类的性能。

何时使用：

    1）需要扩展一个类的功能，或给一个类增加附加责任。

    2）需要动态的给一个对象增加功能，这些功能可以再动态地撤销。

    3）需要增加一些基本功能的排列组合而产生的非常大量的功能，从而使继承变得    不现实。

3、角色组成

    l 抽象构件(Component)角色：给出一个抽象接口，以规范准备接收附加责任的对象。

    l 具体构件(ConcreteComponent)角色：定义一个将要接收附加责任的类

    l 装饰角色(Decorator)：持有一个构件(Component)对象的实例，并定义一个与抽象构件接口一致的接口

    l 具体装饰角色(ConcreteDecorator)：负责给构件对象“贴上”附加的责任

4、举例说明

        咖啡是一种饮料，咖啡的本质是咖啡豆+水磨出来的。咖啡店现在要卖各种口味的咖啡，如果不使用装饰模式，那么在销售系统中，各种不一样的咖啡都要产生一个类，如果有4中咖啡豆，5种口味，那么将要产生至少20个类（不包括混合口味），非常麻烦。使用了装饰模式，只需要11个类即可生产任意口味咖啡（包括混合口味）。

4.1、类图

4.2、源码

Beverage饮料接口

//decorator.h

#ifndef __DECORATOR_H
#define __DECORATOR_H


#include <iostream>
#include <string.h>


using namespace std;


class Beverage {
public:
virtual ~Beverage(){}
virtual char * getDescription(){}
virtual double getPrice(){}
//protected:
Beverage(){}
};

class CoffeeBean1:public Beverage{
public:
CoffeeBean1();
~CoffeeBean1();

char *getDescription();
double getPrice();
private:
char m_strDesc[128];
};


class CoffeeBean2:public Beverage{
public:
CoffeeBean2();
~CoffeeBean2();

char *getDescription();
double getPrice();
private:
char m_strDesc[128];
};



class Decorator:public Beverage{
public:
Decorator(){memset(m_strDesc,0,sizeof(m_strDesc));}
~Decorator(){}
char *getDescription(){return m_strDesc;}
double getPrice(){return 0;}
private:
char m_strDesc[128];
};


class Milk:public Decorator{
public:
Milk(Beverage *beverage);
~Milk();
char *getDescription();
double getPrice();
private:
Beverage *m_pBeverage;
char m_strDesc[128];
};


class Mocha:public Decorator{
public:
Mocha(Beverage *beverage);
~Mocha();
char *getDescription();
double getPrice();
private:
Beverage *m_pBeverage;
char m_strDesc[128];
};


#endif

//decortor.cpp

#include "decorator.h"


CoffeeBean1::CoffeeBean1()
{
memset(m_strDesc,0,sizeof(m_strDesc));
strcpy(m_strDesc,"选择了第一种咖啡豆");
}


CoffeeBean1::~CoffeeBean1()
{

}


char *CoffeeBean1::getDescription()
{
return m_strDesc;
}


double CoffeeBean1::getPrice()
{
return 10.4;
}
-----------------------------------------------
CoffeeBean2::CoffeeBean2()
{
memset(m_strDesc,0,sizeof(m_strDesc));
strcpy(m_strDesc,"选择了第二种咖啡豆");
}


CoffeeBean2::~CoffeeBean2()
{

}


char *CoffeeBean2::getDescription()
{
cout <<"CoffeeBean2::getDescription"<<endl;
return m_strDesc;
}


double CoffeeBean2::getPrice()
{
cout <<"CoffeeBean2::getPrice"<<endl;
return 55.4;
}
-----------------------------------------------
Milk::Milk(Beverage *beverage)
{
m_pBeverage = beverage;
memset(m_strDesc,0,sizeof(m_strDesc));
strcpy(m_strDesc,"加了牛奶");
}


Milk::~Milk()
{

}


char *Milk::getDescription()
{
cout <<"Milk::getDescription: "<<m_strDesc<<endl;
char strDesc[128];

memset(strDesc,0,sizeof(strDesc));
strcpy(strDesc,m_strDesc);
memset(m_strDesc,0,sizeof(m_strDesc));
strcat(m_strDesc,m_pBeverage->getDescription());
strcat(m_strDesc,"\n");
strcat(m_strDesc,strDesc);
return m_strDesc;
}


double Milk::getPrice()
{
cout <<"Milk::getPrice"<<endl;
return m_pBeverage->getPrice()+20.4;
}
-----------------------------------------------
Mocha::Mocha(Beverage *beverage)
{
m_pBeverage = beverage;
memset(m_strDesc,0,sizeof(m_strDesc));
strcpy(m_strDesc,"加了摩卡");
}


Mocha::~Mocha()
{

}


char *Mocha::getDescription()
{
cout <<"Mocha::getDescription"<<endl;
char strDesc[128];

memset(strDesc,0,sizeof(strDesc));
strcpy(strDesc,m_strDesc);
memset(m_strDesc,0,sizeof(m_strDesc));
strcat(m_strDesc,m_pBeverage->getDescription());
strcat(m_strDesc,"\n");
strcat(m_strDesc,strDesc);
return m_strDesc;
}


double Mocha::getPrice()
{
cout <<"Mocha::getPrice"<<endl;
return m_pBeverage->getPrice()+30.4;
}
-----------------------------------------------

//main.cpp

#include "decorator.h"
#include <stdio.h>


int main()
{
Beverage *beverage = new CoffeeBean1();

//printf("%s,%0.2f\n",beverage->getDescription(),beverage->getPrice());
Decorator *pDec = NULL;
pDec = new Milk(beverage);
pDec = new Mocha(pDec);

printf("%s,%0.2f\n",pDec->getDescription(),pDec->getPrice());


return 0;
}

测试结果：

5、装饰模式和适配器模式的关系

        装饰模式和适配器模式都是“包装模式(Wrapper Pattern)”，它们都是通过封装其他对象达到设计的目的的，但是它们的形态有很大区别。

 

　　理想的装饰模式在对被装饰对象进行功能增强的同时，要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。而适配器模式则不然，一般而言，适配器模式并不要求对源对象的功能进行增强，但是会改变源对象的接口，以便和目标接口相符合。

 

　　装饰模式有透明和半透明两种，这两种的区别就在于装饰角色的接口与抽象构件角色的接口是否完全一致。透明的装饰模式也就是理想的装饰模式，要求具体构件角色、装饰角色的接口与抽象构件角色的接口完全一致。相反，如果装饰角色的接口与抽象构件角色接口不一致，也就是说装饰角色的接口比抽象构件角色的接口宽的话，装饰角色实际上已经成了一个适配器角色，这种装饰模式也是可以接受的，称为“半透明”的装饰模式，如下图所示。

 在适配器模式里面，适配器类的接口通常会与目标类的接口重叠，但往往并不完全相同。换言之，适配器类的接口会比被装饰的目标类接口宽。

显然，半透明的装饰模式实际上就是处于适配器模式与装饰模式之间的灰色地带。如果将装饰模式与适配器模式合并成为一个“包装模式”的话，那么半透明的装饰模式倒可以成为这种合并后的“包装模式”的代表。

6、透明性要求

        装饰模式对客户端的透明性要求程序不要声明一个ConcreteComponent类型的变量，而应当声明一个Component类型的变量。

　　用上面的例子来说，必须永远把所有的饮料当成饮料来对待，而如果把饮料变成的加摩卡的饮料当成摩卡，而不是饮料，这是不应当发生的。下面的做法是对的：

[java]  view plain  copy

 print ?

1. Beverage beverage = new CoffeeBean1();  
2. Beverage mochaBeverage = new Mocha(beverage);  

而下面的做法是不对的：

[java]  view plain  copy

 print ?

1. Beverage beverage = new CoffeeBean1();  
2. Mocha mochaBeverage = new Mocha(beverage);  

7、半透明模式

        然而，纯粹的装饰模式很难找到。装饰模式的用意是在不改变接口的前提下，增强所考虑的类的性能。在增强性能的时候，往往需要建立新的公开的方法。即便是在孙大圣的系统（如下图）里，也需要新的方法。比如齐天大圣类并没有飞行的能力，而鸟儿有。这就意味着鸟儿应当有一个新的fly()方法。再比如，齐天大圣类并没有游泳的能力，而鱼儿有，这就意味着在鱼儿类里应当有一个新的swim()方法。

        这就导致了大多数的装饰模式的实现都是“半透明”的，而不是完全透明的。换言之，允许装饰模式改变接口，增加新的方法。这意味着客户端可以声明ConcreteDecorator类型的变量，从而可以调用ConcreteDecorator类中才有的方法：

[java]  view plain  copy

 print ?

1. TheGreatestSage sage = new Monkey();  
2. Bird bird = new Bird(sage);  
3. bird.fly();  

        半透明的装饰模式是介于装饰模式和适配器模式之间的。适配器模式的用意是改变所考虑的类的接口，也可以通过改写一个或几个方法，或增加新的方法来增强或改变所考虑的类的功能。大多数的装饰模式实际上是半透明的装饰模式，这样的装饰模式也称做半装饰、半适配器模式。

8、优点

        （1）装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。装饰模式允许系统动态决定“贴上”一个需要的“装饰”，或者除          掉一个不需要的“装饰”。继承关系则不同，继承关系是静态的，它在系统运行前就决定了。

　　（2）通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。

9、缺点

        使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。