簡單總結:以設計模式的角度總結Java基本IO流

在總結 Java Basic IO 時,發現 java.io 包的相關類真心很多~~。看到一堆「排山倒海」般的類,我想,惟有英雄聯盟中小炮的臺詞才能表現此刻個人心情:html

跌倒了沒?崩潰了沒?java

學 Java 的,學過裝飾者模式通常都知道一個典型的應用:Java 的基本 IO 使用了裝飾者模式(更多的 JDK 中使用的設計模式,請點我)。也所以知道了爲何 io 包裏爲何會有這麼多的類~~,引用《HeadFirst 設計模式》的話:程序員

Java I/O 也引出裝飾者模式的一個「缺點」:利用裝飾者模式,經常形成設計中有大量的小類,數量實在太多,可能會形成使用此 API 程序員的困擾。設計模式

廢話很少說了,直接上裝飾者模式的類圖:
api

看完裝飾者模式的類圖後,再以裝飾者模式的角度來總結下 I/O類:
oracle

因爲InputStream、OutputStream、Reader和Writer的結構大同小異,所以上圖主要給出了InputStream和Reader的詳細子類(一個字節級的,一個字符及的)設計

有了上面的圖片,在使用基本io時就好辦多了。首先根據需求來判斷是操做字節(InputStream 和 OutputStream),仍是操做字符(Reader 和 Writer)來選擇不一樣的分支,而後根據是操做對象仍是文件等來選擇具體的組件(裝飾者模式的 ConcreteComponent),最後根據是否須要緩衝區等功能來使用相應的裝飾者類來包裝具體組件類。code

簡單例子:以字節流方式讀取圖片。由於讀取的是圖片,所以不能選擇字符操做的 Reader,應選擇 InputStream;由於圖片屬於文件系統中的文件,因此選擇FileInputStream;又由於咱們以爲一次讀取一個字節不合適,咱們又使用 BufferedInputStream 來包裝具體組件 FileInputStream。所以有了如下代碼htm

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核心庫的使用對象

相關文章
相關標籤/搜索