本科毕业设计(论文)外文翻译
译文：
Java I/O 系统
对编程语言的设计者来说，创建一套好的输入输出(I/O)系统，是一项难度极高的任务。这一点可以从解决方案的数量之多上看出端倪。这个问题难就难在它要面对的可能性太多了。不仅是因为有那么多I/O的源和目地(文件，控制台，网络连接等等)，而且还有很多方法(顺序的『sequential』，随机的『random-access』，缓存的『buffered』，二进制的『binary』，字符方式的『character』，行的『by lines』，字的『by words』，等等)。 Java类库的设计者们用"创建很多类"的办法来解决这个问题。坦率地说Java I/O系统的类实在是太多了，以至于初看起来会把人吓着（但是，具有讽刺意味的是，这种设计实际上是限制了类的爆炸性增长）。此外，Java在1.0版之后又对其I/O类库作了重大的修改，原先是面向byte的，现在又补充了面向Unicode字符的类库。为了提高性能，完善功能，JDK 1.4又加了一个nio(意思是"new I/O"。这个名字会用上很多年)。这么以来，如果你想对Java的I/O类库有个全面了解，并且做到运用自如，你就得先学习大量的类。此外，了解I/O类库的演化的历史也是相当重要的。可能你的第一反应是"别拿什么历史来烦我了，告诉我怎么用就可以了！"但问题是，如果你对这段历史一无所知，很快就会被一些有用或是没用的类给搞糊涂了。 本章会介绍Javarandom翻译标准类库中的各种I/O类，及其使用方法。 在介绍直接从流里读写数据的类之前，我们先介绍一下处理文件和目录的类。 File类有一个极具欺骗性的名字；或许你会认为这是一个关于文件的类，但它不是。你可以用它来表示某个文件的名字，也可以用它来表示目录里一组文件的名字。如果它表示的是一组文件，那么你还可以用list( )方法来进行查询，让它会返回String数组。由于元素数量是固定的，因此数组会比容器更好一些。如果你想要获取另一个目录的清单，再建一个File对象就是了。实际上，叫它 "FilePath"可能会更好一些。下面我们举例说明怎样使用这个类及其相关的FilenameFilter接口。 假设你想看看这个目录。有两个办法。一是不带参数调用list( )。它返回的是File对象所含内容的完整清单。但是，如果你要的是一个"限制性列表(restricted list)"的话 —— 比方说，你想看看所有扩展名为.java的文件 —— 那么你就得使用"目录过滤器"了。这是一个专门负责挑选显示File对象的内容的类。 也就是说，这类对象的任务就是提供一个accept( )的方法。之所以要创建这个类，就是要给list( )提供一个accept( )方法，这样当
list( )判断该返回哪些文件名的时候，能够"回过头来调用"accept( )方法。因此，这种结构通常被称为回调(callback)。更准确地说，由于list( )实现了基本功能，而FilenameFilter提供了"对外服务所需的算法"，因此这是一种"策略模式(Strategy Pattern)"。由于list( )拿FilenameFilter对象当参数，因此你可以将任何实现FilenameFilter接口的对象传给它，并以此(甚至是在运行时)控制list( )的工作方式。回调能提高程序的灵活性。 DirFilter还告诉我们，interface只是包含了一些方法，它没说你只能写这些方法。(但是，你至少要定义接口里有的方法。) 这里我们还定义了DirFilter的构造函数。 accept( )方法需要两个参数，一个是File对象，表示这个文件是在哪个目录里面的；另一个是String，表示文件名。虽然你可以忽略它们中的一个，甚至两个都不管，但是你大概总得用一下文件名吧。记住，list( )会对目录里的每个文件调用accept( )，并以此判断是不是把它包括到返回值里；这个判断依据就是accept( )的返回值。 切记，文件名里不能有路径信息。为此你只要用一个String对象来创建File对象，然后再调用这个File对象的getName( )就可以了。它会帮你剥离路径信息（以一种平台无关的方式）。然后再在accept( )里面用正则表达式(regular expression)的matcher对象判断，regex是否与文件名相匹配。兜完这个圈子，list( )方法返回了一个数组。 这是用匿名内部类(详见第八章)来重写程序的绝佳机会。下面我们先创建一个返回FilenameFilter的filter( )方法。 注意，filter( )的参数必须是final的。要想在匿名内部类里使用其作用域之外的对象，只能这么做。 这是对前面所讲的代码的改进，现在FilenameFilter类已经与DirList2紧紧地绑在一起了。不过你还可以更进一步，把这个匿名内部类定义成list( )的参数，这样代码会变得更紧凑： 现在该轮到main( )的参数成final了，因为匿名内部类要用它的arg[0]了。 这个例子告诉我们，可以用匿名内部类来创建专门供特定问题用的，一次性的类。这种做法的好处是，它能把解决某个问题的代码全都集中到一个地方。但是从另一角度来说，这样做会使代码的可读性变差，所以要慎重。 File类的功能不仅限于显示文件或目录。它还能帮你创建新的目录甚至是目录路径(directory path)，如果目录不存在的话。此外它还能用来检查文件的属性(大小，上次修改的日期，读写权限等)，判断File对象表示的是文件还是目录，以及删除文件。下面这段程序演示了File类的一些其他方法(请查阅JDK文档，以了解其全部功能)： fileData( )演示了全套查询文件和目录路径信息的方法。 main( )的第一条指令就是执行renameTo( )。它会把文件重命名成(或者说移动到)新的目录，也就是参数所给出的目录。而参数本身就是一个File对象。这个方法也适用于目录。 如果你试过上面那段程序，就会发现，你能用它创建任意复杂的目录路径，因为mkdirs( )已经帮你打理好了。
I/O类库常使用"流(stream)"这种抽象。所谓"流"是一种能生成或接受数据的，代表数据的源和目标的对象。流把I/O设备内部的具体操作给隐藏起来了。 正如JDK文档所显示的，Java的I/O类库分成输入和输出两大部分。所有InputStream和Reader的派生类都有一个基本的，继承下来的，能读取单个或byte数组的read( )方法。同理，所有OutputStream和Writer的派生类都有一个基本的，能写入单个或byte数组的write( )方法。但通常情况下，你是不会去用这些方法的；它们是给其它类用的 —— 而后者会提供一些更实用的接口。因此，你很少会碰到只用一个类就能创建一个流的情形，实际上你得把多个对象叠起来，并以此来获取所需的功能。Java的流类库之所以会那么让人犯晕，最主要的原因就是"你必须为创建一个流而动用多个对象"。 我们最好还是根据其功能为这些class归个类。Java 1.0的类库设计者们是从决定"让所有与输入相关的类去继承InputStream"入手的。同理，所有与输出相关的类就该继承OutputStream了。使用"分层对象(layered objects)"，为单个对象动态地，透明地添加功能的做法，被称为Decorator Pattern。(模式[61]是Thinking in Patterns (with Java)的主题。)Decorator模式要求所有包覆在原始对象之外的对象，都必须具有与之完全相同的接口。这使得decorator的用法变得非常的透明--无论对象是否被decorate过，传给它的消息总是相同的。这也是Java I/O类库要有"filter(过滤器)"类的原因：抽象的"filter"类是所有decorator的基类。(decorator必须具有与它要包装的对象的全部接口，但是decorator可以扩展这个接口，由此就衍生出了很多"filter"类)。 Decorator模式常用于如下的情形：如果用继承来解决各种需求的话，类的数量会多到不切实际的地步。Java的I/O类库需要提供很多功能的组合，于是decorator模式就有了用武之地。[62] 但是decorator有个缺点，在提高编程的灵活性的同时(因为你能很容易地混合和匹配属性)，也使代码变得更复杂了。Java的I/O类库之所以会这么怪，就是因为它"必须为一个I/O对象创建很多类"，也就是为一个"核心"I/O类加上很多decorator。为InputStream和OutputStream定义decorator类接口的类，分别是FilterInputStream和FilterOutputStream。这两个名字都起得不怎么样。FilterInputStream和FilterOutputStream都继承自I/O类库的基类InputStream和OutputStream，这是decorator模式的关键(惟有这样decorator类的接口才能与它要服务的对象的完全相同)。 FilterInputStream及其派生类有两项重要任务。DataInputStream可以读取各种primitive及String。(所有的方法都以"read"打头，比如readByte( )， readFloat( ))。它，以及它的搭档DataOutputStream，能让你通过流将primitive数据从一个地方导到另一个地方。其它的类都是用来修改InputStream的内部行为的：是不是做缓冲，是不是知道它所读取的行信息(允许你读取行号或设定行号)，是不是会弹出单个字符。后两个看上去更像是给编译器用的(也就是说，它们大概是为Java编译器设计的)，所以通常情况下，你是不大会用到它们的。 不论你用哪种I/O设备，输入的时候，最好都做缓冲。所以对I/O类库来说，比较明智的做法还是把不缓冲当特例(或者去直接调用方法)，而不是像现在这样把缓冲当作特例。
原文：
The Java I/O System
Creating a good input/output (I/O) system is one of the more difficult tasks for the language designer.This is evidenced by the number of different approaches. The challenge seems to be in covering all eventualities. Not only are there different sources and sinks of I/O that you want to communicate with (files, the console, network connections, etc.), but you need to talk to them in a wide variety of ways (sequential, random-access, buffered, binary, character, by lines, by words, etc.). The Java library designers attacked this problem by creating lots of classes. In fact, there are so many classes for Java’s I/O system that it can be intimidating at first (ironically, the Java I/O design actually prevents an explosion of classes). There was also a significant change in the I/O library after Java 1.0, when the original byte-oriented library was supplemented with char-oriented, Unicode-based I/O classes. In JDK 1.4, the nio classes (for “new I/O,” a name we’ll still be using years from now) were added for improved performance and functionality. As a result, there are a fair number of classes to learn before you understand enough of Java’s I/O picture that you can use it properly. In addition, it’s rather important to understand the evolution history of the I/O library, even if your first reaction is “don’t bother me with history, just show me how to use it!” The problem is that without the historical perspective, you will rapidly become confused with some of the classes and when you should and shouldn’t use them. This chapter will give you an introduction to the variety of I/O classes in the standard Java library and how to use them. Before getting into the classes that actually read and write data to streams, we’ll look at a utility provided with the library to assist you in handling file directory issues. The File class has a deceiving name; you might think it refers to a file, but it doesn’t. It can represent either the name of a particular file or the names of a set of files in a directory. If it’s a set of files, you can ask for that set using the list( ) method, which returns an array of String. It makes sense to return an array rather than one of the flexible container classes, because the number of elements is fixed, and if you want a different directory listing, you just create a different File object. In fact, “FilePath” would have been a better name for the class. This section shows an example of the use of this class, including the associated FilenameFilter interface. Suppose you’d like to see a directory listing. The File object can be listed in two ways. If you call list( ) with no arguments, you’ll get the full list that the File object contains. However, if you want a restricted list—for example, if you want all of the files with an extension of .java—then you use a “directory filter,” which is a class that tells how to select the File objects for display. Here’s the code for the example. Note that the result has been effortlessly sorted (alphabetically) using the java. It says all that this type of object does is provide a method called accept( ). The whole reason behind the creation of this class is to provide the accept( ) method to the list( ) method so that list( ) can “call back” accept( ) to determine which file names should be included in the list. Thus, this structure is often referred to as a callback. More specifically, this is an example of the Strategy Pattern, because list( ) implements basic functionality, and you provide the Strategy in the form of a FilenameFilter in order to complete the algorithm necessary for list( ) to provide its service. Because list( ) takes a FilenameFilter object as its argument, it means that you can pass an object of any class that implements FilenameFilter to choose (even at run time) how the list( ) method will behave. The purpose of a callback is to provide flexibility in the behavior of code. DirFilter shows that just because an interface contains only a set of methods, you’re not restricted to writing only those methods. (You must at least provide definitions for all the methods in an interface, however.) In this case, the DirFilter constructor is also created.The accept( ) method must accept a File object representing the directory that a particular file is found in, and a String containing the name of that file. You might choose to use or ignore either of these arguments, but you will probably at least use the file name. Remember that the list( ) method is calling accept( ) for each of the file names in the directory object to see which one should be included; this is indicated by the boolean result  returned by accept( ). To make sure the element you’re working with is only the file name and contains no path information, all you have to do is take the String object and create a File object out of it, then call getName( ), which strips away all the path information (in a platform-independent way). Then accept( ) uses a regular expression matcher object to see if the regular expression regex matches the name of the file. Using accept( ), the list( ) method returns an array. Note that the argument to filter( ) must be final. This is required by the anonymous inner class so that it can use an object from outside its scope. This design is an improvement because the FilenameFilter class is now tightly bound to DirList2. However, you can take this approach one step further and define the anonymous inner class as an argument to list( ), in which case it’s even smaller: The argument to main( ) is now final, since the anonymous inner class uses args[0] directly. This shows you how anonymous inner classes allow the creation of specific, one-off classes to solve problems. One benefit of this approach is that it keeps the code that solves a particular problem isolated together in one spot. On the other hand, it is not always as easy to read, so you must use it judiciously. The File class is more than just a representation for an existing file or directory. You can also use a File object to create a new directory or an entire directory path if it doesn’t exist. You can also look at the characteristics of files (size, last modification date, read/write), see whether a File object represents a file or a directory, and delete a file. This program shows some of the other methods available with the File class (see the HTML documentation from java.sun for the full set): In fileData( ) you can see various file investigation methods used to display information about the file or directory path.The first method that’s exercised by main( ) is renameTo( ), which allows you to rename (or move) a file to an entirely new path represented by the argument, which is another File object. This also works with directories of any length. If you experiment with the preceding program, you’ll find that you can make a directory path of any complexity, because mkdirs( ) will do all the work for you.
I/O libraries often use the abstraction of a stream, which represents any data source or sink as an object capable of producing or receiving pieces of data. The stream hides the details of what happens to the data inside the actual I/O device. The Java library classes for I/O are divided by input and output, as you can see by looking at the class hierarchy in the JDK documentation. By inheritance, everything derived from the InputStream or Reader classes 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 1.0, 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. 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 www.BruceEckel.) 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 combination that is needed—so many classes that it becomes impractical. The Java I/O library requires many different combinations 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 complexity 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 common interface to all the objects that are being decorated). The FilterInputStream classes accomplish 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 companion 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 compiler (that is, they were probably added to support the construction of the Java compiler), 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.

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。