从设计模式说起JAVA I/O流

## 从设计模式说起JAVA I/O流 之前写过一篇I/O流的入门介绍,直到最近看了设计模式,顺带理下I/O流的设计思路。

JAVA类库中的I/O类分成输入和输出两部分,通过继承,任何自InputStream或Reader派生而来的类都包含名为read()的基本方法,用于读取单个字节或者字节数组。同样,任何自OutputStream或者Writer派生而来的类都包含有write()的基本方法,用于写单个字节或者字节数组。

但是,我们通常用不到,它们之所以存在是因为别的类可以用到它们,以便提供更有用的接口。因此,我们很少使用单一的类来创建流对象,而是通过叠合多个对象来提供所期望的功能(装饰器模式)。实际上,JAVA中“流”类库让人迷惑的地方主要原因就是:创建单一的结果流,却需要创建多个对象。

InputStream 和 OutputStream之装饰器模式

首先我们介绍下装饰器模式:

定义:动态的将责任附加到对象上,若要扩展功能,装饰者提供了比继承更有弹性的替代方案。


FilterInputStream 是一个抽象装饰者,而InputStream是抽象组件,FileInputStream等是可以被装饰者包起来的具体组件。

OutputStream跟InputStream类似,所以在此不进行列举。

Reader 和 Writer

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。

原文地址:https://www.cnblogs.com/tina-smile/p/5352369.html