详解，文件字符流操作中的缓冲区的这种设计模式，我们在使用和查找API时，看见他们的继承关系，总觉得很奇怪，其实这是一种设计模式——装饰设计模式
假设现在有连个读取类：
TextReader ：读取文本
mediaReader : 读取多媒体
抽取他们的共性：形成体系
Reader
|----- TextReader
|-----MediaReader
现在的需求：
提高读取文本的效率，使用缓冲技术，提供一种更高效的读取方式：
覆盖TextReader 中的方法，建立更高效的read 方法
Reader
|-----TextReader
|-----子类（重写read 方法）
|-----MediaReader
|------
如果Reader 有更多的读取子类，而每个类都需要这样的提高效率的方法，那么，继承的体系将会十分对的臃肿（这是十分不建议的）
抽取所有为提高效率的子类的共性————————这些子类都是需要高效，而且这高效的实现方法都是一样的。都是提供一个缓冲区，所以没有必要每一个对象都存在一个有这样功能重复的子类
将高效抽取：具备缓冲区，重写一个高效的read 方法
那个类需要这个高效的方法，就将那个类传进来
class BufferedReader{
//定义缓冲区
BufferedReader(Reader r){}//构造函数接受被装饰的类
//因为这个增强的方法不是只对于某一个类而是对于，更多的类（与装饰类实现同一个接口的类）
//重写read 方法——————因为还是具备读这个方法，所以这个类还是Reader 的一个子类
}
所以最后的继承体系是：
Reader
|-----TextReader
|-----MediaReader
|-----BufferedReader
这种设计减少了继承体系的臃肿，增加了功能，是这个体系更加的灵活这就是装饰设计模式
解决的问题：给一组类增加一个共性功能，同时避免臃肿
注意：装饰类和被装饰类必须属于同一个体系，通常装饰类都会提供构造函数接受被装饰的对象
装饰类不会单独存在，因为他是为装饰其他类而存在的
装饰类的出现只是为了给对象增加功能，对象还是原来的对象，只是加了一个马甲
举个例子帮助理解：
一个人要今天要走嘻哈风，那么给他穿一件嘻哈的外套，他就嘻哈了
**
总结：
装饰者模式：
要修改的方法必定是装饰者与被修饰者共同具备的共性方法，或者是换一种说法，这就是为什么装饰者和被装饰者要实现或者是继承同一个接口或者方法的原因
使用要求
1.装饰者和被装饰者一定要实现同一个接口或者同一个类
为什么？ 在装饰者类中才能有要装饰的方法
2.装饰者里面一定要有被装饰者的引用
为什么？才能使用被装饰者原来的方法
3.修改要修改的方法其余的使用原来的方法
**
//这是继单例设计模式之后的又一设计模式