为什么使用decorator模式

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

为什么使用？

1： 我们经常使用继承来实现功能的拓展，本来这样一般也没什么问题，但如果需要拓展的种类很多，那么肯定生成很

     多子类。这还不是最致命的，很多时候还需要这些功能子类的组合，如果这时候我们还使用继承，那么这会导致类

     爆炸。如何使“对象功能的扩展”能够根据需要来动态地实现同时又避免“扩展功能的增多”带来的子类膨胀问题。这时

     我们就需要引入装饰模式。

2：装饰模式不仅能使功能扩展变化所导致的影响降为最低，另一个好处是，客户可以动态决定加入功能的方式和时机，

     提供了“即插即用”的方法，方便我们在运行期间决定何时增加何种功能。也就是说 你可以构造一条功能对象链，这

     时候你就可以动态的确定这些功能的执行顺序，该功能链的创建可以有工厂模式来完成。

角色：

component  定义一个对象接口，可以给这些对象动态地添加职责。

concretecomponent  定义一个对象，可以给此对象添加一些职责。

decorator:维持一个指向component 对象的指针，并定义一个与component接口一致的接口。

concrete Decorator:向组件添加职责。

总结：

1 component类在decorator模式中充当接口的角色，不应该去实现具体的行为。

2 decorator类在接口上表现为is -a component的继承关系，但在实现上它又使用了另一个component类，

   我们可以使用一个或多个decorator对象来“装饰”一个component对象，装饰后的对象仍然是一个component对象

3 本模式比较好的地方在于它将继承机制与聚合方式两者结合起来，各自的优点弥补了对方的缺点，装饰者如果不继承

   被装  饰的对象，那就没有了多态的性质。那样客户端调用被装饰对象的地方就不能再调用装饰者对象。

转载于:https://www.cnblogs.com/wangok/archive/2008/12/19/1358199.html