从设计模式说起JAVA I/O流
JAVA类库中的I/O类分成输入和输出两部分，通过继承，任何自InputStream或Reader派生而来的类都包含名为read()的基本方法，用于读取单个字节或者字节数组。同样，任何自OutputStream或者Writer派生而来的类都包含有write()的基本方法，用于写单个字节或者字节数组。
但是，我们通常用不到，它们之所以存在是因为别的类可以用到它们，以便提供更有用的接口。因此，我们很少使用单一的类来创建流对象，而是通过叠合多个对象来提供所期望的功能（装饰器模式）。实际上，JAVA中“流”类库让人迷惑的地方主要原因就是：创建单一的结果流，却需要创建多个对象。
InputStream 和 OutputStream之装饰器模式
首先我们介绍下装饰器模式:
定义：动态的将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案。
FilterInputStream 是一个抽象装饰者，而InputStream是抽象组件，FileInputStream等是可以被装饰者包起来的具体组件。
OutputStream跟InputStream类似，所以在此不进行列举。
Reader 和 Ｗriter
Java1.1对基本的I/O流类库进行了重大的修改。Reader和Writer是所有字符流类的的抽象基类，用于简化对字符串的输入输出编程，即用于读写文本数据。主要是提供兼容Unicode与面向字符的I/O功能。
接下来我们介绍适配器模式。
定义：将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
对象适配器
类适配器
两者的区别就是类适配器继承了target和adaptee。而对象适配器利用组合的方式将请求传送给被适配者。
在Java I/O中，InputStreamReader 将InputStream转为Reader,OutputStreamWriter转换为Writer。
设计Reader和Writer继承层次结构主要是为了国际化。老的I/O流继承层次结构仅支持8位字节流，并且不能很好的处理16位的Unicode字符。由于Unicode用于字符国家化（Java本身的char也是16位的Unicode），所以添加Reader和Writer继承层次结果就是为了在所有的I/O操作中支持Unicode。
