【结构型】Decorate模式

装饰模式主要意图是为对象扩展额外的职责，但对于用户来说，在使用行为上并没有任何的变化。在此举一个例子来解释该模式的含义。假如你手上有一张照片，此时可以给它盖上一片玻璃片，同时再套上一个精美的相框。如此相片就更好看同时又被更好地防护起来。此处的玻璃片以及相框，对于原来的照片来说，都是起到一个装饰的作用。并且，加上这些装饰后的照片，你能说它不是照片吗？不，它还是一个照片，是一个被精美装饰过后的照片。

在编程设计上，上面例子可描述如下：

 class IImage
 {
 public:
     // 图像总是要被绘制出来的
     virtual void draw() {}
 };
 class Photograph : public IImage
 {
 public:
     // some code here........
 };
 class PhotograhDecorate : public IImage
 {
 public:
     // some code here........

 protected:
     inline IImage* getImage() { /* some code here........*/ }

 private:
     IImage* _image;
 };
 class GlassDecorate : public PhotograhDecorate
 {
 public:
     virtual void draw() override {
         getImage()->draw();
         this->drawGlass();
     }

 private:
     void drawGlass() {
         // some code here........
     }

 };

 class FrameDecorate : public PhotograhDecorate
 {
 public:
     virtual void draw() override {
         getImage()->draw();
         this->drawFrame();
     }

 private:
     void drawFrame() {
         // some code here........
     }

 };

相片装饰编码参考

由上面的定义以及例子，可以看出装饰其实是可以无限嵌套下去的。给相片装饰完了玻璃，接着又将装饰完玻璃后的相片一起用相框给装饰上。装饰模式的类关系结构图参考如下：

装饰模式的优缺点分析：

1) 如果前面的相片例子中，不使用装饰模式的话，则用户期望想要一张盖上玻璃片的相片的话，则需要从Photograph类继承下来实现一个玻璃片相片类。如果再想要一个带相框效果的照片，则又需要继承一个分支出来。如果想要一张盖上玻璃片又带相框的照片，则又需要第三个分支。试想下，如果此时还有第三种装饰情况了？比如：在照片的右下角有明星签名显示。那子类的数量就多了N种了。子类的数量是相于当所有装饰效果的组合。如此下去，随着装饰效果种类的增加，Photograph的类系将十分复杂，增量方式是以所有装饰效果的组合数量增长了。

此时如果使用装饰模式，则只需要N个的装饰类即可。需要什么效果，就新增一个装饰类即可。因此，扩展效果十分方便，效果的新增也不会引起Photograph类系的动荡。所写的任何装饰效果都是可以随意组合使用，而且对用户来说，使用上与直接使用照片Photograph类，没有任何区别。

2) 由于增加了装饰类系，因此，系统中就多了许多附加的类。如果一个相片拥有100种附加效果，则就需要增加100个装饰类。这其实也会给系统维护增加难度。

3) 某一类系的装饰类，只是针对某一对象装饰。如果系统中有非常多的对象都有它们自己的装饰类，上面第2)的问题就更加严重。

4) 在使用装饰框时，如果待装饰的对象较为复杂时，比如：前面例子中的相片类很复杂时，则它的装饰类系的实现难度会很大。因此，实现代价也会随之增加。从此点看，在动手设计装饰类前，需要先考虑清楚。