为什么 Java 中那么多操作 IO 流的类呢

Go 也是很少 哈哈哈

多无所谓，但是没有原生的简单文件操作就很烦，读个文件要套好几层

曲线救国，装饰者。Java 语言设计上不允许多继承，只能走装饰者模式。

不算 nio 的话，Java 操作 IO 流的类只有 4 个，其它的全是包装类。

需要关注的就两个类吧，InputStream 、OutputSteam，剩下的都是相关扩展

少嘛?
又不是叫 stream 的才是 stream,
有 write, read 的基本就是了

java 为了处理各种输入输出端和它们之间的通信方式而设计了一个统一的抽象，最初的目的是希望避免有过多的类，最后的结果是，处理 io 的类变得很多，讽刺啊《 java 编程思想》

当时 java 设计的时候脑子抽风了

后面自己也吐槽说弄得不好

历史遗留问题，nio 里的设计保守得多。举个例子，原来的 PrintOStream 的 print(string)。在 nio 里要用 charset.encode(string)得到 byteBuffer，然后 channel.put(byteBuffer)。

@fzhyzamt 读文件好像很简单的，一行代码可以解决吧。了解一下 Java 5 后的 Paths，Files 工具类。

read by lines, Files.lines( Paths.get(filePath), StandardCharsets.UTF_8)
read all bytes, Files.readAllBytes( Paths.get(filePath) )

@hantsy 用过，但是 lines 是读成一个 List，对于那种格式文件还要 join，用起来总是有些不舒服，而且涉及文件全都要再指定一次编码，大多数时候都是直接扔个 utf8

这些设计应该是为了 java 的语言定位吧，可以理解，不过用起来总归不爽

装饰器模式就是可以给你整一大堆类

反正，能用 Apache IO 就不用 JDK 的。慢慢的也就忘了。

@hantsy Paths 是 7 之后才有，lines 合 readAllBytes 也就只能用来读小文件

大概就是这个意思：我封装了你的封装。然后你觉得不好用，你又封装了我封装了你的封装......

@stevenkang 太形象了，有点套娃了 学 IO 流时候怀疑人生。

突然发现 python 任何对象都用 len 一个方法求长度，设计的理念问题

因为设计得稀烂

因为 Java 的语言特性和表达能力。

@stevenkang 套娃？