Java IO流库能满意我们的很多根基要求：可以通过节制台、文件、内存块甚至因特网（拜见第15章）举办读写。可以建设新的输入和输出工具范例（通过从InputStream和OutputStream担任）。向一个原来预期为收到字串的要领通报一个工具时，由于Java已限制了“自动范例转换”，所以会自动挪用toString()要领。而我们可以从头界说这个toString()，扩展一个数据流能采取的工具种类。
在IO数据流库的联机文档和设计进程中，仍有些问题没有办理。好比当我们打开一个文件以便输出时，完全可以指定一旦有人试图包围该文件就“掷”出一个违例——有的编程系统答允我们自行指定想打开一个输出文件，但独一的前提是它尚不存在。但在Java中，好像必需用一个File工具来判定某个文件是否存在，因为如果将其作为FileOutputStream可能FileWriter打开，那么必定会被包围。若同时指定文件和目次路径，File类设计上的一个缺陷就会袒暴露来，因为它会说“不要试图在单个类里做太多的工作”！
IO流库易使我们夹杂一些观念。它确实能做很多工作，并且也可以移植。但如果如果事先没有吃透装饰器方案的观念，那么所有的设计都几多带有一点盲目性质。所以不管学它照旧教它，都要出格花一些工夫才行。并且它并不完整：没有提供对输格外式化的支持，而其他险些所有语言的IO包都提供了这方面的支持（这一点没有在Java 1.1里得以更正，它完全错失了改变库设计方案的时机，反而增添了更非凡的一些环境，使庞洪水平进一步提高）。Java 1.1转到那些尚未替换的IO库，而不是增加新库。并且库的设计人员好像没有很好地指出哪些特性是不赞成的，哪些是首选的，造成库设计中常常城市呈现一些令人恼火的阻挡动静。
然而，一旦把握了装饰器方案，并开始在一些较为机动的情况利用库，就会认识到这种设计的长处。到谁人时候，为此多支付的代码行应该不至于使你以为太生气。
