[四] JavaIO之类层次体系结构横向比对

io家族类层次体系结构横向匹配

上一篇文章中主要介绍了javaio流家族的整体设计思路,简单回顾下

基本逻辑涉及数据源 流的方向,以及流的数据形式这三个部分的组合

按照流的数据形式和流的方向,组合而来了四大家族,分别是:

inputstream/outputstream reader/writer

数据源与四大家族的组合构成了io流的基本功能

数据源形式	inputstream	outputstream	reader	writer
bytearray(字节数组)	bytearrayinputstream	bytearrayoutputstream	无	无
file(文件)	fileinputstream	fileoutputstream	filereader	filewriter
piped(管道)	pipedinputstream	pipedoutputstream	pipedreader	pipedwriter
object(对象)	objectinputstream	objectoutputstream	无	无
string	stringbufferinputstream	无	stringreader	stringwriter
chararray(字符数组)	无	无	chararrayreader	chararraywriter

扩展功能基本通过装饰器模式实现

扩展功能点	inputstream	outputstream	reader	writer
data(基本类型)	datainputstream	dataoutputstream	无	无
buffered(缓冲)	bufferedinputstream	bufferedoutputstream	bufferedreader	bufferedwriter
linenumber(行号)	linenumberinputstream	无	linenumberreader	无
pushback(回退)	pushbackinputstream	无	pushbackreader	无
print(打印)	无	printstream	无	printwriter

从上面的列表应该可以看得出来,对于io体系中的主要的一些类和接口

我们只需要明确两点,就能够更加深入的了解他们

1.针对于各种数据源,四大家族的处理逻辑

2.扩展功能点的含义   

注意:

很多io的成员并不操作磁盘上的文件

比如bytearrayinputstream和bytearrayoutputstream  接下来我们还会详细的介绍到

他们并不直接操作持久化的数据(存储在磁盘上的),还有不少其他的也都不是的

他们跟io有什么关系?为什么他们要实现流的接口?

此处我想要提醒的是,

对于我们程序设计语言来说,io 表示的是对数据的操纵,数据有读写

io代表的是一类可读可写行为类似的事物,而不是指从磁盘上读取文件

为什么不是有一个单纯的类去进行对于字节数组的操作呢,为什么非要跟io挂钩沾边?

首先,这并不是不可以,

的确是可以构造一个跟io体系结构没关系的字节数组

来操纵类进行字节数组的读写

可是,他的行为显然跟io非常的类似,在定义一套不同的接口显然增加开发者使用成本

再者,不管从哪里读 ,本身也仍旧是输入输出的问题

而且,针对不同的数据源提供一致性的接口,这也非常的符合面向接口的编程规范

所以,一句话,不要把io狭隘地理解为操作磁盘上的文件.数据.

io是输入与输出,是读与写的代名词

io数据源应用

bytearray(字节数组)

字节数组,毫无疑问,不会应用在字符家族里面

他应用于 bytearrayinputstream   以及  bytearrayoutputstream

他的内部包含一个 字节数组    byte buf[]

bytearrayinputstream  以及  bytearrayoutputstream  内部维护了一个byte buf[]

会将数据读取到这个字节数组(缓冲区)

或者将数据写入到这个字节数组(缓冲区)

他们维护的是这个内部的字节数组本身,并不会写入文件

这两个类本质就是操纵字节数组,提供对字节数组的读取与写入
它的本质如同文件一样,都是用来存储数据
只不过是数据存在于内存中而已
通过将数据封装到内部的字符数组中,可以提供io一致性的接口

bytearray  仅仅应用与字节流

file(文件)

前面说过,file 是最常见的一种数据形式
所以对io提供针对文件的操作非常合理
我们知道,所有的数据存储最终都是字节的形式
但是对于文件的操作又是如此的频繁和重要
所以,针对于字符的输入输出也提供了对应的处理
不过还是那句话,最终文件都是字节形式存储,所以,对于字符文件,自然需要进行编码与解码
filterreader每一次的读取都意味着一次解码
filterwriter每一次的写入都意味着编码

既然是文件,我们前面介绍过file类
file类的构造主要由路径名或者文件描述符
所以对于文件的输入输出相关的io操作,自然可以通过  路径名  文件描述符  或者file 本身作为目标对象
也就是说构造函数的参数一般都是这三者之一

对于文件的操作是实实在在的操作文件本身
file 四大家族都有应用

piped(管道)

管道的概念,不是来自于java io很早前就有此概念
含义非常明朗,就如同他的名字一样,管道,好像两个水管连接起来,形成一个通道
这个通道是直接连接的,并不会再跑到别的地方去弯弯绕
管道流的主要作用是可以进行两个线程间的通讯
既然主要作用进行线程间的通讯,他就是传输数据使用的
in 字节数组缓存数据,out使用in对象

管道在四大家族中都有应用

object

objectinputstream 和 objectoutputstream 的作用是，对基本数据和对象进行序列化操作支持

objectoutputstream对象能提供对“基本数据或对象”的持久存储

objectinputstream，读取出这些“基本数据或对象”

只有支持 java.io.serializable 或 java.io.externalizable 接口的对象才能被objectinputstream/objectoutputstream所操作

序列化自然不可能就只有字符,所以object仅仅针对字节家族

string

提供了对string类型的支持
reader读取到string
writer写入到stringbuffer

stringbufferinputstream  已经不推荐使用了
所以,后续可以认为string仅仅支持字符家族

chararray

类似bytearray,也是提供对字符数组的支持
操纵内存数据

字符数组仅仅支持字符家族

其实可以看得出来,只有file才是真正跟磁盘文件相关的

其他的数据源形式都是操作内存数据

io扩展功能应用

data(基本类型)

data是对基本数据类型的支持
针对于dataoutputstream写出的数据文件
可以使用datainputstream进行读取
也就是说是一种特殊形式的文件

他们底层依赖的还是字节流  通过继承filterinputstream 和 filteroutputstream
使用其中的inputstream in   以及  outputstream out
这两个对象是通过构造方法传递进来的

buffered(缓冲)

缓冲也就是为了减少读取的频率,设置一个缓冲区
缓冲的概念到处都是,所以缓冲应用于四大家族

linenumber(行号)

linenumber是针对输入的
所以存在于linenumberinputstream和linenumberreader
不过对于字节流的linenumberinputstream 已经弃用

linenumberreader是一个跟踪行号的缓冲字符输入流
也很显然,流都是顺序读取不能回退的,所以想要读取行号自然要借助于缓存
他的实现继承bufferedreader 也很好理解

pushback

pushback 回退,也就是读取了一个字符,然后再次把它放回到流中
所以是针对输入的
pushbackinputstream  pushbackreader
也是借助于内部的缓存

print(打印)

主要是为了提供数据打印的便利性

打印自然是针对于输出的
printstream  printwriter

本文从数据源以及扩展功能点的角度,再次分析了io类库的整体设计

虽然上一篇文章中对于所有的基本功能点以及扩展功能点已经做了一个介绍

本文再次提及是为了着重强调,数据源与扩展功能点在类层次结构中涉及的重要性

只有彻底明确了数据源以及扩展功能点的逻辑

才能彻底理解整个io类库架构设计