设计模式C++描述----10.装饰(Decorator)模式

一. 举例

我之前做过一个文件系统就叫 MyFileSys 吧，后来的话，客户想加入一些附加功能，比如压缩、加密、杀毒之类的操作，这些附加操作没有先后顺序，比如你可以先压缩再加密，也可以先杀毒再压缩，等等。

这些附加功能是可选的，有的客户要这些功能，有的不要，有的要其中的几种附加功能等等。怎么设计呢？

第一种方案：
直接修改这个独立的文件系统 MyFileSys，对于不同的客户实现不同的文件系统。

后来随着客户的增多，发现维护和修改的工作量越来越大。因为每增加一个客户就要重新生成一个类，然后把客户想要的附加功能加入，更加郁闷的是，只针对一个客户有时也是要修改很多次，客户今天要这些附加功能，明天又想加入另外一些功能，这样改来改去，维护工作量也是很大的。

第二种方案：

后来改用第二种方案，实现一个单独的附加功能类，保持原文件系统不变，这样在客户端就可以轻松的加入一些附加功能。

代码如下：

//定义一个对象接口，可以给这些对象动态地添加职责
class FileSys
{
public:
    virtual ~FileSys()
    {
    }

    virtual void Operation()
    {
    }
protected:
    FileSys()
    {
    }
};

//定义一个具体的对象
class MyFileSys:public FileSys
{
public:
    MyFileSys()
    {
    }

    ~MyFileSys()
    {
    }

    void Operation()
    {
        cout<<"MyFileSys operation..."<<endl;
    }
};

//装饰抽象类
class Decorator:public FileSys
{
public:
    Decorator(FileSys* fileSys)
    {
        this->_fileSys = fileSys;
    }

    virtual ~Decorator()
    {
        delete _fileSys;
    }

    void Operation()
    {
    }
protected:
    FileSys* _fileSys;
};

//压缩装饰类
class ZipDecorator:public Decorator
{
public:
    ZipDecorator(FileSys* fileSys):Decorator(fileSys)
    {
    }

    ~ZipDecorator()
    {
    }
    
    void Operation()
    {
        _fileSys->Operation(); //首先运行以前的功能
        
        this->AddedZipBehavior(); //附加功能
    }
    
    void AddedZipBehavior()
    {
        cout<<"Added Zip Behavior...."<<endl;
    }
};

//杀毒装饰类
class KillVirDecorator:public Decorator
{
public:
    KillVirDecorator(FileSys* fileSys):Decorator(fileSys)
    {
    }
    
    ~KillVirDecorator()
    {
    }
    
    void Operation()
    {
        _fileSys->Operation();
        
        this->AddedKillVirBehavior();
    }
    
    void AddedKillVirBehavior()
    {
        cout<<"Added Kill Virus Behavior...."<<endl;
    }
};

//加密装饰类
class EncryptDecorator:public Decorator
{
public:
    EncryptDecorator(FileSys* fileSys):Decorator(fileSys)
    {
    }
    
    ~EncryptDecorator()
    {
    }
    
    void Operation()
    {
        _fileSys->Operation();
        
        this->AddedEncrypeBehavior();
    }
    
    void AddedEncrypeBehavior()
    {
        cout<<"Added Encrypt Behavior...."<<endl;
    }
};

//
//测试
int main()
{
    FileSys* fileSys = new MyFileSys();
    
    Decorator* dec1 = new ZipDecorator(fileSys);  //在原文件系统上，加入压缩功能
    Decorator* dec2 = new KillVirDecorator(dec1); //在之前的基础上，加入杀毒功能
    Decorator* dec3 = new EncryptDecorator(dec2); //再加入加密功能

    dec3->Operation();

    return 0;
}

这样之后，如果要添加附加功能，实现起来就很方便了。这种模式就是装饰模式。

二. 装饰模式

装饰模式：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。

说明：

Componet，主要是定义一个接口，通过这个接口可以给这些对象（ConcreteComponent）添加职责。

Dectorator，装饰类，通过外类（ConcreteDecorator）来扩展Component 类的功能，对于Component来说，是无需知道这个抽象类的存在的。

ConcreteDecorator，具体装饰类，添加具体的附加功能。

优点：

1. 装饰类是为已有功能动态地添加更多功能的一种方式。

2. 有效地把类的核心职责和装饰功能区分开，而且可以去除相关类中重复的装饰逻辑。

三. 问题讨论

从上图可以看到 Decorator 是继承于 Component 的，也就和 ConcreteComponent 成了兄弟了，但是 Decorator 的作用却是修饰 ConcreteComponent 的，这点好像是很怪怪的！！最说不通的是Decorator 与 Component 是没有is-a关系的！！

我个人觉得：

1. 这个继承关系，不应该是我们要重点关注的。这里使用继承主要是为了要重用 Operation() 这个接口，以达修饰的目的。

2. 重点是 Decorator 与 Component 这个组合关系。装饰类里有一个Component 指针，正是由于它的存在才能修饰到具体的 Component 对象。