设计模式阅读笔记（3）-----------装饰者模式

装饰者模式（Decorator)可以动态的将职责附加到对象上。若要扩展功能，装饰者提供了比继承更加弹性的解决方案。

刚阅读的时候可能会产生疑惑，装饰者持有了超类的一个引用，目的是为了能够拥有被装饰者的行为，这时候会觉得和继承好像没有差别，因为继承其实也是保留了父类的一个引用的，那在子类中调用super.operation()不是一样的效果吗？后来仔细的想想，应该用发展的眼光来看问题，当类的数量只有几个的时候，似乎是用继承也能达到效果，但是想到那句老话，继承是在编译时静态的决定了子类的行为。而组合的好处是可以在运行时动态的扩展行为。使用继承来实现的话，会导致类的数量成指数级增长。

由于继承是静态的，就要在使用前将所有的类写好，形成一颗很复杂的树（单继承情况下）或者网（可以多继承），考虑完所有情况后，使用者挑一个类来使用。而装饰者模式相当于把节点配置好，让使用者来构建自己需要的组合。这样当要新加入一个行为的使用，前者会产生巨大的麻烦，而后者只相当于添加一个节点。

按现实生活中来理解的话，就是为一个主体附加上功能。机械的组装可能比较好理解。假如我们需要能飞行的汽车，那我们的主体是汽车。按继承来实现，设计一个飞行汽车类继承汽车类，按装饰者来实现则是飞行器装饰者类，汽车主体类，然后在使用时候组装：飞行器装饰者（汽车主体类）；这样看起来，两者差别不是很大。当我们出现新的要求，需要一个能飞行，能入水的汽车。继承使用者就要添加飞行入水汽车类继承飞行汽车类，那如果只能入水呢？于是继承使用者又要添加入水汽车类。而装饰器使用者只需增加水中推进器装饰者类，使用时组装：水中推进器装饰者（飞行器装饰者（汽车主体类）），入水的话就组装：水中推进器装饰者（汽车主体类）。如果我们要添加自行车主体呢？继承使用者就有的忙了，要设计能飞行，能入水，同时能飞行和入水的三个类。而装饰者模式只要添加自行车主体类就可以了。

我们来看看该模式具体是怎么实现的，图是从别人博客中截来的，不过原图是《HeadFirst 设计模式》里面的：

图中ConcreteComponent就是待装饰的主体，ConcreteDecoratorA和B就是具体的装饰者，这里需要特别注意的地方时,Decorator既继承了Component,又组合（component= contains-a) Component；我们需要知道的是Decorator继承Component并不是为了获得Component的行为（它已经组合了Component了，可以获得行为），而是为了使Decorator和ConcreteComponent类型匹配，这样的话，装饰者可以继续装饰被装饰过的对象。

在java中，装饰者使用体现在了io类的设计上，初学者使用的时候可能会感到疑惑对类似的代码：

BufferedReader br =new BufferedReader(new FileReader(new File( "D:\\1.xls")));

在了解了装饰器模式后，我们就可以明白，这是使用了装饰器来为主体类拓展行为。具体可以查阅io类的UML图可以有进一步的体会