装饰器模式

装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。

这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。

我们通过下面的实例来演示装饰器模式的用法。其中，我们将把一个形状装饰上不同的颜色，同时又不改变形状类。

介绍

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

主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。

何时使用：在不想增加很多子类的情况下扩展类。

如何解决：将具体功能职责划分，同时继承装饰者模式。

关键代码： 1、Component 类充当抽象角色，不应该具体实现。 2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。

应用实例： 1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。 2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。

优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

缺点：多层装饰比较复杂。

使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销。

注意事项：可代替继承。

 

以上摘录自菜鸟教程

以下为个人理解

这依然是一个望文生义的设计模式，修饰如其意义是非主要的，你有了主体才能修饰装饰对不对。但是确实使主要的被修饰部分产生了不同。

正如上文所说修饰是为了减少子类继承而引起的膨胀。比如你有很多间间木房子，但是这些房子有有所不同。有的里面地板有点，有的窗有所不同，有的里面多了一副普通通的画。但是最后你都叫他们木房子，你没有专门叫某一个某某房子（比如窗户高一毫米房子）。因为这样区别太费脑子每一个都有不同的名字怎么记得住啊。

相似的这里也是一样如果你想要向一个房子类里面放一些不同的画。由于画这个字段（属性）不同你每个房子都新建一个类，那么数量就太庞大了。想想你下次换*时岂不是就已经有成千上万个类了。没有必要所以才有修饰类。我们只要知道房子里面有画就行了什么画到时候再挂

public Class House {

　　Painting painting;

　　House（..(不包括画)）{

　　　　....

　　}

　　

　　public paintingdecorator(Painting painting){

　　　　this.painting = painting;

　　}

　　

　　public paintingremove(){

　　　　this.painting = null;

　　}

}

 

public interface Painting(){

　　...

}

 

//然后你就可以加入你想要的画只要它实现了Painting接口