【正文】 sses have basic methods called read() for reading a single byte or array of bytes. Likewise, everything derived from OutputStream or Writer classes have basic methods called write() for writing a single byte or array of bytes. However, you won’t generally use these methods。 they exist so that other classes can use them—these other classes provide a more useful interface. Thus, you’ll rarely create your stream object by using a single class, but instead will layer multiple objects together to provide your desired functionality. The fact that you create more than one object to create a single resulting stream is the primary reason that Java’s stream library is confusing. It’s helpful to categorize the classes by their functionality. In Java , the library designers started by deciding that all classes that had anything to do with input would be inherited from InputStream, and all classes that were associated with output would be inherited from OutputStream.Types of InputStreamInputStream’s job is to represent classes that produce input from different sources. These sources can be: 1. An array of bytes. 2. A String object. 3. A file. 4. A “pipe,” which works like a physical pipe: You put things in at one end and they e out the other. 5. A sequence of other streams, so you can collect them together into a single stream. 6. Other sources, such as an Internet connection. (This is covered in Thinking in Enterprise Java.) Each of these has an associated subclass of InputStream. In addition, the FilterInputStream is also a type of InputStream, to provide a base class for decorator classes that attach attributes or useful interfaces to input streams. This is discussed later.Types of OutputStreamThis category includes the classes that decide where your output will go: an array of bytes (no String, however。 presumably, you can create one using the array of bytes), a file, or a “pipe.” In addition, the FilterOutputStream provides a base class for decorator classes that attach attributes or useful interfaces to output streams.Adding attributes and useful interfacesThe use of layered objects to dynamically and transparently add responsibilities to individual objects is referred to as the Decorator pattern. (Patterns 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 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 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).Reading from an InputStream with FilterInputStreamThe 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. These “places” are determined by the classes in Table 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.Writing to an OutputStream with FilterOutputStreamThe plement to DataInputStream is DataOutputStream, which formats each of the primitive types and String objects onto a stream in such a way that any DataInputStream, on any machine, can read them. All the methods start with “write,” such as writeByte(), writeFloat(), etc.The original intent of PrintStream was to print all of the primitive data types and String objects in a viewable format. This is different from DataOutputStream, whose goal is to put data elements on a stream in a way that DataInputStream can portably reconstruct them.The two important methods in PrintStream are print() and println(), which are overloaded to print all the vari