【導(dǎo)讀】這個問題難就難在它要面。對的可能性太多了。不僅是因為有那么多I/O的源和目地(文件，控制臺，網(wǎng)絡(luò)連接。等等)，而且還有很多方法(順序的『sequential』，隨機(jī)的『random-access』，緩存的?！篵uffered』，二進(jìn)制的『binary』，字符方式的『character』，行的『bylines』，字的?！篵ywords』，等等)。Java類庫的設(shè)計者們用"創(chuàng)建很多類"的辦法來解決這個問題。諷刺意味的是，這種設(shè)計實際上是限制了類的爆炸性增長）。為了提高性能，完善功能，JDK又加了一個nio(意思是"newI/O"。這個名字會用上很多年)。此外，了解I/O類庫的演化的歷史也是。本章會介紹Java標(biāo)準(zhǔn)類庫中的各種I/O類，及其使用方法。于元素數(shù)量是固定的，因此數(shù)組會比容器更好一些。們舉例說明怎樣使用這個類及其相關(guān)的FilenameFilter接口。它返回的是File對象所含內(nèi)容的完整清單。挑選顯示File對象的內(nèi)容的類。對象表示的是文件還是目錄，以及刪除文件。文檔所顯示的，Java的I/O類庫分成輸入和輸出兩大部分。

　　

【正文】 had anything to do with input would be inherited from InputStream, and all classes that were associated with output would be inherited from OutputStream. The use of layered objects to dynamically and transparently add responsibilities to individual objects is referred to as the Decorator pattern. (Patterns[61] are the subject of Thinking in Patterns (with Java) at .) The decorator pattern specifies that all objects that wrap around your initial object have the same interface. This makes the basic use of the decorators transparent—you send the same message to an object whether it has been decorated or not. This is the reason for the existence of the “filter” classes in the Java I/O library: The abstract “filter” class is the base class for all the decorators. (A decorator must have the same interface as the object it decorates, but the decorator can also extend the interface, which occurs in several of the “filter” classes). Decorators are often used when simple subclassing results in a large number of classes in order to satisfy every possible bination that is needed—so many classes that it bees impractical. The Java I/O library requires many different binations of features, and this is the justification for using the decorator pattern.[62] There is a drawback to the decorator pattern, however. Decorators give you much more flexibility while you’re writing a program (since you can easily mix and match attributes), but they add plexity to your code. The reason that the Java I/O library is awkward to use is that you must create many classes—the “core” I/O type plus all the decorators—in order to get the single I/O object that you want. The classes that provide the decorator interface to control a particular InputStream or OutputStream are the FilterInputStream and FilterOutputStream, which don’t have 本科畢業(yè)設(shè)計（論文）外文翻譯 7 very intuitive names. FilterInputStream and FilterOutputStream are derived from the base classes of the I/O library, InputStream and OutputStream, which is the key requirement of the decorator (so that it provides the mon interface to all the objects that are being decorated). The FilterInputStream classes acplish two significantly different things. DataInputStream allows you to read different types of primitive data as well as String objects. (All the methods start with “read,” such as readByte( ), readFloat( ), etc.) This, along with its panion DataOutputStream, allows you to move primitive data from one place to another via a stream. The remaining classes modify the way an InputStream behaves internally: whether it’s buffered or unbuffered, if it keeps track of the lines it’s reading (allowing you to ask for line numbers or set the line number), and whether you can push back a single character. The last two classes look a lot like support for building a piler (that is, they were probably added to support the construction of the Java piler), so you probably won’t use them in general programming. You’ll need to buffer your input almost every time, regardless of the I/O device you’re connecting to, so it would have made more sense for the I/O library to make a special case (or simply a method call) for unbuffered input rather than buffered input.