一、装饰模式概述
Decorator模式动态的给一个对象添加一些额外的职责。就添加功能来说，Decorator模式相比生成子类更为灵活。
以下情况适合使用Decorator模式：1、在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责；2、处理那些可以撤销的职责；3、当不能产用生成子类的方法进行扩充时。
Decorator模式的类图如下：
参与者：
Component：装饰器模式中公共方法的类，处于装饰器模式结构图的顶层。
ConcreateComponent：装饰器模式中具体被装饰的类，IO包中的媒体流就是此种对象。
Decorator：装饰器模式中的核心对象，所有具体装饰器对象的父类，完成装饰器的部分职能。该类可以只做一些简单的包裹被装饰的对象，也可以还包含对Component中方法的实现……他有一个鲜明的特点：继承至Component，同时包含一个Component作为其成员变量。装饰器模式动机中的动态地增加功能是在这里实现的。
ConcreteDecoratorA和ConcreteDecoratorB是两个具体的装饰器对象，他们完成具体的装饰功能。装饰功能的实现是通过调用被装饰对象对应的方法，加上装饰对象自身的方法。这是装饰器模式动机中的添加额外功能的关键。
注意，ConcreteDecoratorA和ConcreteDecoratorB的方法不完全一样，这就是一般设计模式中谈及装饰器模式的“透明装饰器”和“不透明装饰器”。“透明装饰器”就是整个Decorator的结构中所有的类都保持同样的“接口”（这里是共同方法的意思），这是一种极其理想的状况。现实中绝大多数装饰器都是“不透明装饰器”，他们的“接口”在某些子类中得到增强。
二 、JDK中的装饰器模式
在jdk中使用了装饰器模式的是IO类库。说实话，我并不是很喜欢java的IO类库，因为在我使用Java的这一年多时间里，我快被Java I/O类库中那些功能相似，却又绝对可称得上庞杂的类搞得要发疯了，只是想简单的输入输出而已，却要创建出3、4个类，比之C/C++复杂多了！
但是学了装饰器模式之后，我终于搞明白为什么JDK中要设计出这么多功能相似的几十个类出来，因为java I/O库就使用了装饰器模式，它比继承模式更灵活，可扩展性更强。
java I/O库类层次结构图如下：
三 、关于装饰器模式的思考
关于装饰器模式至少有两个主要优点和两个缺点：1、比静态继承更灵活；2、避免在层次结构高层的类有太多的特征；3、Decorator和Component不一样；4、有许多小对象。
这几个特点在java I/O库中表现的十分明显！