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

由遇到的问题引出的装饰模式

在 OO 设计和开发过程，可能会经常遇到以下的情况：我们需要为一个已经定义好的类添加新的职责（操作），通常的情况我们会给定义一个新类继承自定义好的类，这样会带来一个问题（将在本模式的讨论中给出）。通过继承的方式解决这样的情况还带来了系统的复杂性，因为继承的深度会变得很深。

而装饰提供了一种给类增加职责的方法，不是通过继承实现的，而是通过组合。

有关这些内容在讨论中进一步阐述。
模式选择
装饰模式典型的结构图为：

图 2-1：装饰Pattern 结构图

在 结 构 图 中 ， ConcreteComponent 和装饰需 要 有 同 样 的 接 口 ， 因 此ConcreteComponent 和装饰有着一个共同的父类。这里有人会问，让装饰直接维护一个指向 ConcreteComponent 引用（指针）不就可以达到同样的效果，答案是肯定并且是否定的。肯定的是你可以通过这种方式实现，否定的是你不要用这种方式实现，因为通过这种方式你就只能为这个特定的 ConcreteComponent 提供修饰操作了，当有了一个新的ConcreteComponent 你 又 要 去 新 建 一 个装饰来 实 现 。 但 是 通 过 结 构 图 中 的ConcreteComponent 和装饰有一个公共基类，就可以利用 OO 中多态的思想来实现只要是 Component 型别的对象都可以提供修饰操作的类，这种情况下你就算新建了 100 个Component 型别的类 ConcreteComponent，也都可以由装饰一个类搞定。这也正是装饰模式的关键和威力所在了。

当然如果你只用给 Component 型别类添加一种修饰，则装饰这个基类就不是很必要了。

装饰模式的实现

完整代码示例（code）：装饰模式的实现起来并不是特别困难，这里为了方便初学者的学习和参考，将给出完整的实现代码（所有代码采用 C++实现，并在 VC 6.0 下测试运行）。

代码片断 1：Decorator.h

//Decorator.h
#ifndef _DECORATOR_H_
#define _DECORATOR_H_
class Component{
    public:
    virtual ~Component();
    virtual void Operation();
    protected:
    Component();
    private:
};

class ConcreteComponent:public Component{
    public:
    ConcreteComponent();
    ~ConcreteComponent();
    void Operation();
    protected:
    private:
};
class Decorator:public Component{
    public:
    Decorator(Component* com);
    virtual ~Decorator();
    void Operation();
    protected:
    Component* _com;
    private:
};
class ConcreteDecorator:public Decorator{
    public:
    ConcreteDecorator(Component* com);
    ~ConcreteDecorator();
    void Operation();
    void AddedBehavior();
    protected:
    private:

};
#endif //~_DECORATOR_H_

代码片断 2：Decorator.cpp

//Decorator.cpp
#include "Decorator.h"
#include <iostream>
Component::Component(){
}
Component::~Component(){
}
void Component::Operation(){
}
ConcreteComponent::ConcreteComponent(){
}
ConcreteComponent::~ConcreteComponent(){
}
void ConcreteComponent::Operation(){
    std::cout<<"ConcreteComponent operation..."<<std::endl;
}
Decorator::Decorator(Component* com){
    this->_com = com;
}
Decorator::~Decorator(){
    delete _com;
}
void Decorator::Operation(){
}
ConcreteDecorator::ConcreteDecorator(Component*com):Decorator(com){
}
ConcreteDecorator::~ConcreteDecorator(){
}
void ConcreteDecorator::AddedBehavior(){
    std::cout<<"ConcreteDecorator::AddedBehacior...."<<std::endl;
}
void ConcreteDecorator::Operation(){
    _com->Operation();
    this->AddedBehavior();
}

代码片断 3：main.cpp

//main.cpp
#include "Decorator.h"
#include <iostream>
using namespace std;
int main(int argc,char* argv[]){
    Component* com = new ConcreteComponent();
    Decorator* dec = new ConcreteDecorator(com);
    dec->Operation();
    delete dec;
    return 0;
}

代码说明：装饰模式很简单，代码本身没有什么好说明的。运行示例代码可以看到，Concrete装饰给 ConcreteComponent 类添加了动作 AddedBehavior。

关于装饰模式的讨论

装饰模式和组合模式有相似的结构图，其区别在组合模式已经详细讨论过了，请参看相应文档。另外 GoF 在《设计模式》中也讨论到装饰和 Proxy 模式有很大程度上的相似，初学设计模式可能实在看不出这之间的一个联系和相似，并且它们在结构图上也很不相似。实际上，在本文档 2.2 节模式选择中分析到，让装饰直接拥有一个 ConcreteComponent 的引用（指针）也可以达到修饰的功能，大家再把这种方式的结构图画出来，就和代理很相似了！

装饰模式和代理模式的相似的地方在于它们都拥有一个指向其他对象的引用（指针），即通过组合的方式来为对象提供更多操作（或者装饰模式）间接性（代理模式）。

但是他们的区别是，代理模式会提供使用其作为代理的对象一样接口，使用代理类将其操作都委托给代理直接进行。这里可以简单理解为组合和委托之间的微妙的区别了。

装饰模式除了采用组合的方式取得了比采用继承方式更好的效果，装饰模式还给设计带来一种"即用即付"的方式来添加职责。在 OO 设计和分析经常有这样一种情况：为了多态，通过父类指针指向其具体子类，但是这就带来另外一个问题，当具体子类要添加新的职责，就必须向其父类添加一个这个职责的抽象接口，否则是通过父类指针是调用不到这个方法了。这样处于高层的父类就承载了太多的特征（方法），并且继承自这个父类的所有子类都不可避免继承了父类的这些接口，但是可能这并不是这个具体子类所需要的。而在装饰模式提供了一种较好的解决方法，当需要添加一个操作的时候就可以通过装饰模式来解决，你可以一步步添加新的职责。