在總結 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核心庫的使用