英文翻译

郑州轻工业学院

专科毕业设计（论文）

英文翻译

题目基于iWebOffice中间件的

文档管理系统

学生姓名黄炳全

专业班级计算机科学与技术2001级2班

学号01471222

院（系）软件职业技术学院

指导教师张建伟（副教授）

完成时间 2005 年 6 月10 日

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22 英文原文

Bruce Eckel. Thinking in Java, 2nd edition(part). America: electronic books

Hiding the Implementation

A primary consideration in object-oriented design is “separating the things that change from the things that stay the same.”

This is particularly important for libraries. Users (client programmers) of that library must be able to rely on the part they use, and know that they won’t need to rewrite code if a new version of the library comes out. On the flip side, the library creator must have the freedom to make modifications and improvements with the certainty that the client code won’t be affected by those changes.

This can be achieved through convention. For example, the library programmer must agree to not remove existing methods when modifying a class in the library, since that would break the client programmer’s code. The reverse situation is thornier, however. In the case of a field, how can the library creator know which fields have been accessed by client programmers? This is also true with methods that are only part of the implementation of a class, and not meant to be used directly by the client programmer. But what if the library creator wants to rip out an old implementation and put in a new one? Changing any of those members might break a client programmer’s code. Thus the library creator is in a strait jacket and can’t change anything.

To solve this problem, Java provides access specifiers to allow the library creator to say what is available to the client programmer and what is not. The levels of access control from “most access” to “least access” are public, protected, package access (which has no keyword), and private. From the previous paragraph you might think that, as a library designer, you’ll want to keep everything as “private” as possible, and expose only the methods that you want the client programmer to use. This is exactly right, even though it’s often counterintuitive for people who program in other languages (especially C) and are used to accessing everything without restriction. By the end of this chapter you should be convinced of the value of access control in Java.

The concept of a library of components and the control over who can access the components of that library is not complete, however. There’s still the questio n of how the components are bundled together into a cohesive library unit. This is controlled with the package keyword in Java, and the access specifiers are affected by whether a class is in the same package or in a separate package. So to begin this chap ter, you’ll learn how library components are placed into

2

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22

packages. Then you’ll be able to understand the complete meaning of the access specifiers.

package: the library unit

A package is what becomes available when you use the import keyword to bring in an entire library, such as

import java.util.*;

This brings in the entire utility library that’s part of the standard Java distribution. For instance, there’s a class called ArrayList in java.util, so you can now either specify the full name java.util.ArrayList(which you can do without the import statement), or you can simply say ArrayList(because of the import).

If you want to bring in a single class, you can name that class in the import statement

import java.util.ArrayList;

Now you can use ArrayList with no qualification. However, none of the other classes in java.util are available.

The reason for all this importing is to provide a mechanism to manage name spaces. The names of all your class members are insulated from each other. A method f( ) inside a class A will not clash with an f( )that has the same signature (argument list) in class B. But what about the class names? Suppose you create a Stack class that is installed on a machine that already has a Stack class that’s written by someone else? This potential clashing of names is why it’s important to have complete control over the name spaces in Java, and to be able to create a completely unique name regardless of the constraints of the Internet.

Most of the examples thus far in this book have existed in a single file and have been designed for local use, so they haven’t bothered with package names. (In this case the class name is placed in the “default package.”) This is certainly an option, and for simplicity’s sake this approach will be used when ever possible throughout the rest of this book. However, if you’re planning to create libraries or programs that are friendly to other Java programs on the same machine, you must think about preventing class name clashes.

When you create a source-code fil e for Java, it’s commonly called a compilation unit (sometimes a translation unit). Each compilation unit must have a name ending in .java, and inside the compilation unit there can be a public class that must have the same name as the file (including capitalization, but excluding

3

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22 the .java filename extension). There can be only one public class in each

compilation unit, otherwise the compiler will complain. If there are additional classes in that compilation unit, they are hidden from the world outside that package because they’re not public, and they comprise “support” classes for the main public class.

When you compile a .java file, you get an output file for each class in the .java file. Each output file has the name of a class in the .java file, but with an extension of .class. Thus you can end up with quite a few .class files from a small number of .java files. If you’ve programmed with a compiled language, you might be used to the compiler spitting out an intermediate form (usually an “obj” file) that is then packaged together with others of its kind using a linker (to create an executable file) or a librarian (to create a library). That’s not how Java works. A working program is a bunch of .class files, which can be packaged and compressed into a Java ARchive (JAR) file (using Java’s jar archiver). The Java interpreter is responsible for finding, loading, and interpreting[26] these files.

A library is a group of these class files. Each file has one class that is public (you’re not forced to have a public class, but it’s typical), so there’s one component for each file. If you want to say that all these components (each in their own separate .java and .class files) belong together, that’s where the package keyword comes in.

When you say:

package mypackage;

at the beginning of a file (if you use a package statement, it must appear as the first noncomment in the file), you’re stating that this compilation unit is part of a library named mypackage. Or, put another way, you’re saying that the public class name within this compilation unit is under the umbrella of the name mypackage, and anyone who wants to use the name must either fully specify the name or use the import keyword in combination with mypackage (using the choices given previously). Note that the convention for Java package names is to use all lowercase letters, even for intermediate words.

For example, suppose the name of the file is MyClass.java. This means there can be one and only one public class in that file, and the name of that class must be MyClass (including the capitalization):

package mypackage;

public class MyClass {

// . . .

4

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22

Now, if someone wants to use MyClass or, for that matter, any of the other public classes in mypackage, they must use the import keyword to make the name or names in mypackage available. The alternative is to give the fully qualified name:

mypackage.MyClass m = new mypackage.MyClass();

The import keyword can make this much cleaner:

import mypackage.*;

// . . .

MyClass m = new MyClass();

It’s worth keeping in mind that what the package and import keywords allow you to do, as a library designer, is to divide up the single global name space so you won’t have clashing names, no matter how many people get on the Internet and start writing classes in Java.

Creating unique package names

You might observe that, since a package never really gets “packaged” into a single file, a package could be made up of many .class files, and things could get a bit cluttered. To prevent this, a logical thing to do is to place all the .class files for a particular package into a single directory; that is, use the hierarchical file structure of the operating system to your advantage. This is one way that Java references the problem of clutter; you’ll see the other way later when the jar utility is introduced.

Collecting the package files into a single subdirectory solves two other problems: creating unique package names, and finding those classes that might be buried in a directory structure someplace. This is accomplished, as was introduced in Chapter 2, by encoding the path of the location of the .class file into the name of the package. By convention, the first part of the package name is the reversed Internet domain name of the creator of the class. Since Internet domain names are guaranteed to be unique, if you follow this convention, your package name will be unique and you’ll never have a name clash. (Th at is, until you lose the domain name to someone else who starts writing Java code with the same path names as you did.) Of course, if you don’t have your own domain name, then you must fabricate an unlikely combination (such as your first and last name) to create unique package names. If you’ve decided to start publishing Java code, it’s worth the relatively small effort to get a domain name.

The second part of this trick is resolving the package name into a directory on your machine, so when the Java program runs and it needs to load the .class file (which it does dynamically, at the point in the program where it needs to

5

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22

create an object of that particular class, or the first time you access a static member of the class), it can locate the directory where the .class file resides.

The Java interpreter proceeds as follows. First, it finds the environment variable CLASSPATH[27] (set via the operating system, and sometimes by the installation program that installs Java or a Java-based tool on your machine). CLASSPATH contains one or more directories that are used as roots in a search for .class files. Starting at that root, the interpreter will take the package name and replace each dot with a slash to generate a path name from the CLASSPATH root (so package foo.bar.baz becomes foo\bar\baz or foo/bar/baz or possibly something else, depending on your operating system). This is then concatenated to the various entries in the CLASSPATH. That’s where it looks for the .class file with the name corresponding to the class you’re trying to create. (It also searches some standard directories relative to where the Java interpreter resides).

To understand this, consider my domain name, which is http://www.wendangku.net/doc/11712403b52acfc789ebc9bf.html. By reversing this, com.bruceeckel establishes my unique global name for my classes. (The com, edu, org, etc., extensions were formerly capitalized in Java packages, but this was changed in Java 2 so the entire package name is lowercase.) I can further subdivide this by deciding that I want to create a library named simple, so I’ll end up with a package name:

package com.bruceeckel.simple;

Now this package name can be used as an umbrella name space for the following two files:

//: com:bruceeckel:simple:Vector.java

// Creating a package.

package com.bruceeckel.simple;

public class Vector {

public Vector() {

System.out.println("com.bruceeckel.simple.Vector");

}

} ///:~

When you crea te your own packages, you’ll discover that the package statement must be the first noncomment code in the file. The second file looks much the same:

//: com:bruceeckel:simple:List.java

// Creating a package.

package com.bruceeckel.simple;

6

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22

public class List {

public List() {

System.out.println("com.bruceeckel.simple.List");

}

} ///:~

Both of these files are placed in the subdirectory on my system:

C:\DOC\JavaT\com\bruceeckel\simple

If you walk back through this, you can see the package name com.bruceeckel.simple, but what about the first portion of the path? That’s taken care of in the CLASSPATH environment variable, which is, on my machine:

CLASSPATH=.;D:\JAVA\LIB;C:\DOC\JavaT

You can see that the CLASSPATH can contain a number of alternative search paths.

There’s a variation when using JAR files, however. You must put the name of the JAR file in the classpath, not just the path where it’s located. So for a JAR named grape.jar your classpath would include:

CLASSPATH=.;D:\JAVA\LIB;C:\flavors\grape.jar

Once the classpath is set up properly, the following file can be placed in any directory:

//: c05:LibTest.java

// Uses the library.

import com.bruceeckel.simpletest.*;

import com.bruceeckel.simple.*;

public class LibTest {

static Test monitor = new Test();

public static void main(String[] args) {

Vector v = new Vector();

List l = new List();

monitor.expect(new String[] {

"com.bruceeckel.simple.Vector",

"com.bruceeckel.simple.List"

});

}

} ///:~

7

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22

When the compiler encounters the import statement for the simple library, it begins searching at the directories specified by CLASSPATH, looking for subdirectory com\bruceeckel\simple, then seeking the compiled files of the appropriate names (Vector.class for Vector, and List.class for List). Note that both the classes and the desired methods in Vector and List must be public.

8

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22 英文翻译

Java的隐藏实现

在面向对象的设计中，最关键的问题就是“将会变和不会变的东西分离开来。”这一点对类库尤为重要。类库的使用者（客户程序员）应该能完全仰赖类库，他们知道，即使类库出了新版本，他们也不必重写代码。另一方面，类库的创建者也应该可以在确保不影响客户程序员代码的前提下，保留对类库作修正和改进的权利。

要达到上述目的，可以使用约定。比方说，类库的开发人员必须遵守：修改类的时候不删除现有的方法，因为这可能会影响客户程序员的代码。但是还有一些更棘手的问题。就拿成员数据来说，类库的开发人员又怎么知道客户程序员会使用哪些数据呢？对于那些只与类的内部实现有关的，不应该让客户程序员使用的方法来说，情况也一样。但是，如果类库的开发人员想用一种新的实现来替换旧的，那他又该怎么做呢？对类的任何修改都可能会破坏客户程序员的代码。这样，类库的开发人员就被套上了紧箍咒，什么都不能改了。为了解决这个问题，Java提供了访问控制符（access Specifier）这样类库的开发人员能告诉客户程序员，他们能用什么，不能用什么了。访问控制权限从松到紧依次是public，protected，package权限（也就是不给任何关键词），以及private。读了上面那段，你可能会认为，作为类库的设计者，你应该尽可能的把所有东西都做成“private”的，并且只公开你想让客户程序员使用的方法。完全正确！尽管对于那些用其它语言（特别是C）编程，并且己经习惯了不受限制地访问任何东西的人来说，这么做通常是有违常理的。读过本章之后，你就会对Java的访问控制更有信心了。但是，什么是组件类库（library of component）以及怎样去控制“谁能访问类库中组件”的问题还没有完全解决。还有一个问题，就是组件是怎样被捆绑成一个联系紧密的类库单元的。这是由Java的package关键词控制的，此外类是不是属于同一个package，还会对访问控制符产生影响。所以，我们将从怎样将类库组件（library components）放入Package里入手，开始本章的学习。接下来，你就能完全理解访问控制符的意思了。package：类库的单元

当你使用import关键词引入一个完整的类库的时候，这个package就能为你所用了，例如

import java.util.*；

会把Java标准版里的工具类库（utility library）全都引进来。比如，java．util 里面有一个ArrayList类，因此你既可以用全名java．util．ArrayList(这样用不着import语句了），也可以直接写ArrayList了（因为己经有了import）。如果你只想引入一个类，那你可以在import语句里面指名道姓地引用类了。

import java.util.ArrayList；

现在你就可以直接使用ArrayList而不用添加任何限定词了。但是java．util里面的其它的类就不能用了。之所以要使用import，是因为它提供了一种管理名字空间（nameSpaces）的机制。类的所有成员的名字都是相互独立的。A类里面的f（）方法不会同B类里面，有着相同“调用特征（signiture，即参数列表）”的f(）相冲突。但是类的名字呢？假设你创建了一个stack类，并且把它装到一台己经有了一个别人写的stack类的机器上，那又会发生什么事呢？Java之所以要对名字空间拥有完全的控制，就是要解决这种潜在的名字冲突，并且能不受Internet的束缚，创建出完全唯一的名字。到目前为止，本书所举的都是单文件的例子，而且都是在本地运行的，因此没

9

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22

必要使用package。（在这种情况下，类的名字是放在“defaultpackage”的名下的。）当然这也是一种做法，而且为了简单起见，本书的其余章节也尽可能使用这种方法。但是，如果你打算创建一个，能同机器上其它Java程序相互兼容的类库或程序，你就得考虑一下如何避免名字冲突了。Java的源代码文件通常被称为编译单元（compilation unit有时也称翻译单元translation unit）。每个编译单元都必须是一个以．java结尾的文件，而且其中必须有一个与文件名相同的public类（大小写也必须相同，但是不包括．java的文件扩展名）。每个编译单元只能有一个public类，否则编译器就会报错。如果编译单元里面还有别的类，那么这些类就成了这个主要的public的类的“辅助”类了，这是因为它们都不是public的，因此对外面世界来说它们都是看不到的。编译．java文件的时候，它里面的每个类都会产生输出。其输出文件的名字就是．java 文件里的类的名字，但是其扩展名是．class。这样，写不了几个．java文件就会产生一大堆．class文件。如果你有过用编译语言编程的经验，那么你可能会对这个过程感到习以为常了：先用编译器生成一大堆中间文件（通常是“obj”文件），然后再用linker 创建可执行文件）或librarian（创建类库）把这些中间文件封装起来。但是，Java不是这样工作的。一个能正常工作的程序就是一大堆．class文件，当然也可以（用Java 的jar工具）把它们封装和压缩成 Java ARchive （JAR）文件。Java解释器会负责寻找，装载和解释这些文件的。类库就是一组类文件。每个文件都有一个public类（不是一定要有public类，但通常都是这样），因此每个文件都代表着一个组件。如果你想把这些组件（都在它们自己的那个．java和．class文件里）都组织起来，那就应该用package关键词了。当你把：package mypackage；放到文件开头的时候（如果要用package，那么它必须是这个文件的第一个非注释的行），你就声明了，这个编译单元是mypackage类库的组成部分。或者换一种说法，你要表达的意思是，这个编译单元的public类的名字是在 mypackage的名字之下的（under the umbrella of the name mypackage），任何想使用这个类的人必须使用它的全名，或者用 import关键词把mypackage引进来（用前面讲的办制。注意Java的约定是用全小写来表示package的名字，中间单词也不例外。

举例来说，假设这个文件的名字是 MyClass．java。于是文件里面可以有，而且只能有一个public类，而这个类的名字只能是MyClass（大小写都要相同）：

package mypackage；

public classMyClass｛

//…

现在如果有人想要用MyClass，或者mypackage里面的其它public类，那他就必须使用import关键词来引入mypackage下的名字了。还有一个办法，就是给出这个类的全名： mypackage.MyClass m＝new mypackage.MyClass（）;

用import可以让代码显得更清楚一点：

Import mypackage.*;

//…

MyClass m＝new MyClass（）;

作为类库的设计者，你得记住，package和 import这两个关键词的作用是要把一个单独的全局名字空间分割开来，这样不论Internet上有多少人在用Java编程，你就都不会碰到名字冲突的问题了。

创建独一无二的package名字

可能你也发现了，由于package没有被真的“封装”成一个单独的文件，而package又是由很多．class文件组成的，因此事情就有点乱了。要解决这个问题，较为明智的做

10

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22

法是把所有同属一个包的．class文件都放到一个目录里；也就是利用操作系统的层次文件结构来解决这个问题。这是Java解决这个问题的方法之一；后面要介绍的jar程序是另一个解决办法。

将package的文件收进一个单独的子目录里还解决了另外两个问题：创建独一无二的package名字，以及帮助Java在复杂的目录结构中找到它们。我们己经在第2章讲过了，这是通过将．class文件的路径信息放到package的名字里面来完成的。Java的约定是package名字的第一部分应该是类的创建者的Internet域名的反写。由于Internet域名的唯一性是有保证的，因此只要你遵守这个约定，package的名字就肯定是唯一的，这样就不会有名字冲突的问题了。（除非你把域名让给了别人，而他又用同一个域名来写Java程序。）当然，如果你还没有注册域名，那你完全可以编一个（比如用你的姓和名），然后用它来创建Package的名字。如果你打算要发布Java程序，那么还是应该稍微花点精力去搞个域名。这个技巧的第一部分是把package的名字映射到本地机器的目录，这样当你启动Java程序，需要装载．class文件的时候（当程序需要创建某个类的对象，或者第一次访问那个类的static成员的时候，它会动态执行这个过程的），它就知道该在哪个目录寻找这个．class文件了。JAVA解释器是这样工作的。首先，它要找到 CLASSPATH环境变量（这是通过操作系统设置的，有时Java安装程序或者Java 工具的安装程序会为你设置）。CLASSPATH包含了一个或多个目录，这些目录会被当作根目录供Java搜索．class文件。从这个根目录出发，解释器会将

Package名字里的每个点都换成斜杠（因此，根据操作系统的不同，package foo.bar.baz 就被转换成foo＼bar＼baz或foo／bar／baz，或者其它可能的形式），这样它生成了以 CLASSPATH为根的相对路径。然后这些路径再与CLASSPATH里的各条记录相连。这才是Java用package的名字寻找．class文件的地方。（此外，它还会根据Java解释器所在的位置查找一些标准目录。）为了能讲得更清楚，就拿我的域名bruceeckel．com 举例。它倒过来就是com．bruceeckel，这样我写的类就有了全球唯一的名字了。（过去，com，edu，org这些扩展，在Java的package名字里面是要大写的，但是Java 2作了改进，所以现在package的名字都是小写的。）我还可以进一步分下去，创建一个名为simple的类库，所以Package的名字是：

package com.bruceeckel.simple；

现在，你就能用这个package的名字来管下面这两个文件了：

//：com：bruceeckel：simple：Vector.java

//creating a package。

package com.bruceeckel.simple；

public class Vector｛

public Vector（）｛

system.out.println（com.bruceeckel.simple.vector）J

｝

｝///:~

等到你要自己写package的时候，你就会发现，package语句必须是文件里的第一个非注释行。第二个文件看上去非常相似：

//：com:bruceeckel:simple:List.java

//creating a package.

package combruceeckel.simple；

public class List｛

public List（）｛

11

翻译题目：Java的隐藏实现专业班级：计算机科学与技术姓名：黄炳全学号：22

system.out.println（＂com.bruceeckel.simple.List＂）J ｝

｝///:～

在我的机器上这两个文件都放在这个子目录里：

C:\DOC\JavaT\com\bruceeckel\simple

只要看一遍这个路径，你就会发现Package的名字com．bruceeckel．simple，但是这个路径的前面部分又是什么呢？这是由CLASSPATH环境变量控制的，在我的机器上，它是：

CLASSPATH＝.；D：＼JAVA＼LIB；C：＼DOC＼JavaT

你会看到CLASSPATH可以有好几个可供选择的搜索路径。但是，使用JAR文件的时候会有一点变化。除了要告诉它该到哪里去找这个JAR文件，你必须将文件名放到CLASSPATH 里面。所以对名为rape．jar的 JAR来说，CLASSPATH应该包括：

CLASSPATH＝.;D:\JAVA\LIB；C:\flavors\grape.jar

设完CLASSPATH之后，下面这个文件就可以放在任何目录里了：

//c05：LibTest.java

//Uses the library.

Import com.bruceeckel.simpletest.*;

import com.bruceeckel.simple.*;

public classLibTest｛

static Test monitor＝new Test（）；

public static void main（string［］args）｛

Vector v＝new Vector（）；

List＝new List（）;

monitor.expect（new string［］｛

＂com.bruceeckel.simple.Vector＂，

＂com.bruceeckel.simple.list＂

｝）；

｝

｝///:~

当编译器碰到了simple类库的import语句的时候，它就开始在CLASSPATH所给出的目录下搜索，先找com＼bruceeckel＼simple子目录，再找编译后的文件（Vector就找Vector．class，List就找List．class）。注意Vector和 List类，以及其中要用的方法都必须是public的。

12