简单总结：以设计模式的角度总结Java基本IO流

在总结 Java Basic IO 时，发现 java.io 包的相关类真心不少～～。看到一堆“排山倒海”般的类，我想，唯有英雄联盟中小炮的台词才能表现此刻我的心情：

跌倒了没？崩溃了没？

学 Java 的，学过装饰者模式一般都知道一个典型的应用：Java 的基本 IO 使用了装饰者模式（更多的 JDK 中使用的设计模式，请点我）。也因此知道了为什么 io 包里为什么会有这么多的类～～，引用《HeadFirst 设计模式》的话：

Java I/O 也引出装饰者模式的一个“缺点”：利用装饰者模式，常常造成设计中有大量的小类，数量实在太多，可能会造成使用此 API 程序员的困扰。

废话不多说了，直接上装饰者模式的类图：

看完装饰者模式的类图后，再以装饰者模式的角度来总结下 I/O类：

由于InputStream、OutputStream、Reader和Writer的结构大同小异，因此上图主要给出了InputStream和Reader的详细子类（一个字节级的，一个字符及的）

有了上面的图片，在使用基本io时就好办多了。首先根据需求来判断是操作字节（InputStream 和 OutputStream），还是操作字符（Reader 和 Writer）来选择不同的分支，然后根据是操作对象还是文件等来选择具体的组件（装饰者模式的 ConcreteComponent），最后根据是否需要缓冲区等功能来使用相应的装饰者类来包装具体组件类。

简单例子：以字节流方式读取图片。因为读取的是图片，因此不能选择字符操作的 Reader，应选择 InputStream；因为图片属于文件系统中的文件，所以选择FileInputStream；又因为我们觉得一次读取一个字节不合适，我们又使用 BufferedInputStream 来包装具体组件 FileInputStream。因此有了以下代码

InputStream ips = new BufferedInputStream( new FileInputStream("..."));

Java API 文档Java Basic I/O官方教程The Decorator pattern and Java.IO package(装饰者模式与Java IO包)(需扶梯)深入分析 Java I/O 的工作机制设计模式在Java核心库的使用