设计模式学习笔记－装饰模式

设计模式学习笔记

 

摘要：以下为Tree_ch的设计模式学习笔记

 

装饰模式

 

1.引言
如果我们对自己所居住的房间不满意的时候，我们往往是通过装修的方式来使我们的房间变的漂亮起来。而不是重新建一个房间。而且经过装修的屋子仍让是原来的屋子，本质不会变，但它的确变漂亮了，满足了我们的美的需求。从投入来看，装修比重新建设显然要便宜的多! 在软件设计里面，此类情形的设计既可以采用装饰模式(Decorator)来完成。
2.概念与模式

装饰模式（Decorator）也叫包装器模式（Wrapper）。GOF在《设计模式》一书中给出的定义为：动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
装饰模式的实现类关系图为：

1)        抽象构件角色（Component）：定义一个抽象接口，以规范准备接收附加责任的对象。

2)        具体构件角色(Concrete Component)：这是被装饰者，定义一个将要被装饰增加功能的类。

3)        装饰角色(Decorator)：持有一个构件对象的实例，并定义了抽象构件定义的接口。

4)        具体装饰角色(Concrete Decorator)：负责给构件添加增加的功能。

3.应用实例
一部手机，在其接受到来电的时候，会发出声音来提醒主人。而现在我们需要为该手机添加一项功能，在接收来电的时候，产生震动，而令一部更加高级，不仅发声，而且振动，而且有灯光闪烁。
用装饰模式来解决这个问题的类关系图为：

 

 

 

以下为我用C++实现的实例：

#include <iostream>

using namespace  std;

//Component
class IPhone... {
public:
    virtual void ReceiveCall() = 0;
} ;

//Concrete Component
class BasePhone:public IPhone... {
public:
    virtual void ReceiveCall()
    ...{
        printf("Ring... ");
    }
} ;

//Decorator
class PhoneDecorator:public IPhone... {
private:
    IPhone* pphone;
public:
    PhoneDecorator(IPhone* pphone)
    ...{
        if(pphone != NULL)
        ...{
            this->pphone = pphone;
        }
        else
        ...{
            this->pphone = new BasePhone();
        }
    }

    virtual void ReceiveCall()
    ...{
        pphone->ReceiveCall();
    }

} ;

//Concrete Decorator
class JarPhone:public PhoneDecorator... {
public:
    JarPhone(BasePhone* phone):PhoneDecorator(phone)
    ...{
    }
    virtual void ReceiveCall()
    ...{
        PhoneDecorator::ReceiveCall();
        printf("Jar... ");
    }
} ;

class ComplexPhone:public PhoneDecorator... {
public:
    ComplexPhone(JarPhone* phone):PhoneDecorator(phone)
    ...{
    }
    virtual void ReceiveCall()
    ...{
        PhoneDecorator::ReceiveCall();
        printf("Wink... ");
    }
} ;


//Client
int  main()
... {    
    BasePhone* pphone = new BasePhone();
    pphone->ReceiveCall();
    printf("--------------------- ");
    JarPhone* p2 = new JarPhone(pphone);
    p2->ReceiveCall();
    printf("--------------------- ");
    ComplexPhone* p3 = new ComplexPhone(p2);
    p3->ReceiveCall();
    
    delete p3;
    delete p2;
    delete pphone;
    
    return 0;
}

运行结果：

4．应用环境 
       GOF书中给出了以下使用情况： 
1)        在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。 

2)        处理那些可以撤消的职责。  

3)        当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。  

来分析下手机的使用是属于哪种情况。首先实现了比静态继承更加灵活的方式，动态的增加功能。试想为手机的所有实现类通过继承来增加一个功能，意味着要添加不少的功能类似的子类，这明显是不太合适的。 

而且，这就避免了高层的类具有太多的特征。 

5．透明和半透明  

       对于面向接口编程，应该尽量使客户程序不知道具体的类型，而应该对一个接口操作。这样就要求装饰角色和具体装饰角色要满足Liskov替换原则。

6．其它 

采用Decorator模式进行系统设计往往会产生许多看上去类似的小对象，这些对象仅仅在他们相互连接的方式上有所不同，而不是它们的类或是它们的属性值有所不同。尽管对于那些了解这些系统的人来说，很容易对它们进行定制，但是很难学习这些系统，排错也很困难。这是GOF提到的装饰模式的缺点，你能体会吗？他们所说的小对象我认为是指的具体装饰角色。这是为一个对象动态添加功能所带来的副作用。