Decorator模式

1.定义：

   动态的给一个对象添加一些额外的职责。比生成子类更加灵活。

   工作原理是：创建始于Decorator对象，终于原对象的一个对象链。

   此模式的核心是让功能对象变为装饰对象链。

   Concrete 具体的

   Decorator 装饰对象

   抽象类Decorator和ConcreteComponent都继承抽象类Component，Decorator并且包含了抽象类Component的引用，装饰对象可以通过构造函数传参来包装被装饰对象。

   抽象类Component中声明了功能函数。

   根据里氏代换原则，ConcreteComponent、ConcreteDecorator都是被装饰对象。

  

2.装饰模式的变通

   如果只有一个ConcreteComponent类，而没有抽象的Component类，那么Decorator类可以继承ConcreteComponent。

   如果只有一个ConcreteDecorator类，就没必要建立抽象的Decorator类，只需一个ConcreteDecorator类。

3.

      装饰模式解决的是需要在主类中增加新的字段、方法或逻辑，不是修改原有逻辑，而这些新加入的东西只是在特定情况下才需要。这些新东西即是装饰功能，把它们放在单独的类中，并让这个类包装它所要装饰的对象。

     相比在原类中修改，装饰模式简化了原有类，有效地把类的核心职责和装饰功能区分开了。

      客户代码在运用中，要根据需要有选择地、按顺序地组合装饰对象。

   若采用继承机制，类数量可能会无限量增加（类爆炸），或者各种需求组合数量会将我们淹没；
   若采用组合却失去了继承的许多优势，其中，不具备对象的多态特质，就是最大的一个局限。

   如果将继承机制与组合方式结合起来，各自的优点弥补了各自的缺点，完美地解决了“为已有对象动态添加新的职责”的需求。

   Decorator模式并不通过一个控制方法，来控制新功能，而是建议以需要的正确顺序，将所需功能串联起来。

   Decorator模式将一个功能链的动态构建，与使用功能的客户分离，灵活的使用功能组件。

   Decorator模式帮助我们将问题分为两部分：如何实现新功能的对象；如何为每种特殊情况组织对象。

   每个Decorator对象只关心自己添加的功能，不关心自己被添加到对象链中的顺序，这样将Decorator对象的实现，与决定如何使用Decorator的对象分离，提高了内聚性，

  

4.java中的多种流采用的就是装饰模式。

   对一个数据源可以有任意数量在输入流上执行的操作。

   流类都继承自java.io.InputStream类，它们是被装饰对象；装饰对象都直接或间接的派生自FilterInputStream类。

 

5.Decorator模式的适用场合是，各种可选的功能，在另一个肯定要执行的功能之前或之后执行。

   例如，发送一条信息之前，可能需要加密，压缩等。

   而我们一般实际上是在功能类中扩展功能。

   教程中的示例有：穿衣，打印票据。它们都是通过重写Component中的功能函数，在其中增加自己要处理的逻辑，然后调用被装饰对象的逻辑。最后形成一个装饰链。