# 10.10 總結 Java IO流庫能滿足我們的許多基本要求：可以通過控制臺、文件、內存塊甚至因特網（參見第15章）進行讀寫。可以創建新的輸入和輸出對象類型（通過從`InputStream`和`OutputStream`繼承）。向一個本來預期為收到字符串的方法傳遞一個對象時，由于Java已限制了“自動類型轉換”，所以會自動調用`toString()`方法。而我們可以重新定義這個`toString()`，擴展一個數據流能接納的對象種類。 在IO數據流庫的聯機文檔和設計過程中，仍有些問題沒有解決。比如當我們打開一個文件以便輸出時，完全可以指定一旦有人試圖覆蓋該文件就“拋”出一個異常——有的編程系統允許我們自行指定想打開一個輸出文件，但唯一的前提是它尚不存在。但在Java中，似乎必須用一個`File`對象來判斷某個文件是否存在，因為假如將其作為`FileOutputStream`或者`FileWriter`打開，那么肯定會被覆蓋。若同時指定文件和目錄路徑，`File`類設計上的一個缺陷就會暴露出來，因為它會說“不要試圖在單個類里做太多的事情”！ IO流庫易使我們混淆一些概念。它確實能做許多事情，而且也可以移植。但假如假如事先沒有吃透裝飾器方案的概念，那么所有的設計都多少帶有一點盲目性質。所以不管學它還是教它，都要特別花一些功夫才行。而且它并不完整：沒有提供對輸出格式化的支持，而其他幾乎所有語言的IO包都提供了這方面的支持（這一點沒有在Java 1.1里得以糾正，它完全錯失了改變庫設計模式的機會，反而增添了更特殊的一些情況，使復雜程度進一步提高）。Java 1.1轉到那些尚未替換的IO庫，而不是增加新庫。而且庫的設計人員似乎沒有很好地指出哪些特性是不贊成的，哪些是首選的，造成庫設計中經常都會出現一些令人惱火的反對消息。 然而，一旦掌握了裝飾器方案，并開始在一些較為靈活的環境使用庫，就會認識到這種設計的好處。到那個時候，為此多付出的代碼行應該不至于使你覺得太生氣。