java中英文文献

导教师评语： 签名： 年 月 日 注： 请将该封面与附件装订成册。 附件 １： 外文资料翻译译文 Java 的面向对象编程 ——面向对象编程和它的关键技术—继承和多态性 软件的重用可以节省程序开发时间。 它鼓励重复使用已经调试好的高质量的软件， 从而减少系统运行后可能出现的问题。 这些都是令人振奋的可能性。 多态性允许我们用统一的风格编写程序， 来处理多种已存在的类和特定的相关类。 利用多态性我们可以方便地向系统中添加新的功能。 继承和多态对于解决软件的复杂性是一种有效可行的技术。 当创建一个新的类时， 而不用完整的写出新的实例变量和实例方法， 程序员会指定新的类继承已定义的超类的实例变量和实例方法。 这个新的类被称为一个子类。 每个子类本身将来亦可有新的子类， 而其本身将成为父类。 一个类的直接父类就是该类所直接继承的类（通过关键字 extends 继承）。 一个间接超类是通过从两级或更多级以上的类继承而来的。例如， 从类 JApplet （包 javax. swing中）扩展来的类 Applet （包 java. applet）。一个类单一的从一个父类继承而来。 Java不支持多重继承（而 C++可以）， 但它支持接口的概念。 接口可以使 Java 实现许多通过多重继承才能实现的优点而没有关联的问题。 我们将在本章讨论的接口的详细内容。 我们会给出创建和使用接口的一般规律和具体实例。 一个子类通常添加自己的实例变量和自己的实例方法， 因此子类通常比父类大。 一个子类比它的父类更具体并且代表一组更小、 更专业的对象。 通过单一继承， 子类在开始时拥有父类的所有特性。 继承性真正的力量在于它可以在定义子类时增加或取代从超类中继承来的特征。 每个子类对象也是该类的父类的对象。 例如， 每一个我们所定义的小程序被认为是类 JApplet 的对象。 此外， 因为 Japplet 继承了 Applet， 每一个我们所定义的小程序同时也被认为是一个 Applet 的对象。 当开发 applets 时， 这些信息是至关重要的， 因为一个小程序容器只有当它是一个 Applet 才可以执行一个程序。虽然子类对象始终可以作为它的父类的一种来看待， 父类对象却不被认为是其子类类型的对象。 我们将利用这种“子类对象是父类对象” 的关系来执行一些强大的操作。 例如， 绘图程序可以显示一系列图形， 如果所有的图形类型都直接或间接地继 承同一超类， 绘图程序就可以将所有图形存储在一个超类对象数组或其他数据结构中。 正如我们将要在这一章中看到的， 这种处理单一类型的一系列的对象的能力是推动面向对象程序发展的重要推动力。 我们添加一个新的成员访问的一种控制形式——protected 访问。 由同一个包中子类和其他类的方法组成的父类可以访问受保护的父类的成员。 开发软件的实践经验表明， 处理的代码的重要部分涉及密切相关的案例。 因为设计人员和程序员十分专注于特殊案例， 所以很难在这种系统中看到 “大局”。 面向对象编程提供 “透过树木见森林” 的几种方法。 程序员和设计人员专注于系统中对象的共性而不是特定实例， 这种方法叫做抽象。 如果一个程序性方案有许多密切相关的案例， 那么就会常用到 switch 交换结构或嵌套的 if / else 结构从而区分众多的案例并提供独立处理各个案例的逻辑。我们下面将学习如何使用继承性和多态性以更简单的逻辑来代替 switch 结构。 我们区分“is a” 关系和“has a” 的关系。 “is a” 就是继承。 在 “是” 关系中，子类类型的对象也可以被看作是它的父类型的对象处理。 “有” 是一种构成。 在“有” 关系中， 一个类对象有一个或多个其它类的对象作为成员。 例如， 车有方向盘。 子类的方法可能需要确切访问它的父类的实例变量和方法。 在 Java 中， 软件工程的一个至关重要的方面就是子类不能访问其父类的私有成员。 如果子类可以访问父类的私有成员， 这就违背了父类的信息隐蔽原则。 然而， 一个子类可以访问它的父类的 public 成员和 protected 成员。 如果子类和父类在同一个包中， 子类也可以使用它的程序包访问父类成员。 如果超类不允许通过继承产生的子类访问它的某些成员， 则需要用 private 声明成员。 子类只可以通过公有继承、 受保护继承和程序包借助父类提供的继承到子类中的方法声明对父类中私有成员的改变。 继承会带来的问题是， 子类会将一些没必要继承或不该继承方法也继承过来。类的编写者应确保由类提供的功能对未来的子类是适用的。 即使父类的方法对

子类适用， 子类也可以使该方法来完成特定于子类的方式的任务。 在这种情况下， 子类可以覆盖超类的方法， 以提供一种合适的实现。 也许最令人兴奋的是一个新类可以从丰富的类库中继承， 比如 Java API 提供许多类。 一些组织开发自己的类库的同时还具有可以利用现有的全球其他库的优势。 总有一天， 大多数的软件可以通过可重用的标准化的组件来构建， 就像现在制造硬件一样。 这将有助于面对开发我们将来可能需要的更加强大的软件的挑战。 我们常常会遇到这样一个问题， 一个类的对象同时还“是” 另一个类的对象。矩形肯定是一个四边形（如同正方形， 平行四边形和梯形）。 因此， Rectangle 类可以说是从 Quadrilateral 类继承而来的。 在这种情况下， Quadrilateral 类是父类， Rectangle 类是一个子类。 矩形是特殊的四边形， 但却不能说四边形就是矩形（四边形可能是平行四边形）。 继承通常能够产生比其父类具有更多功能的子类， 所以父类和子类的概念很容易引起混淆。 然而， 我们还有另种一更好的方法来区分这两个概念。 因为每个子类对象也“是” 其父类的对象， 而一个父类又可以有很多子类， 那么由父类所代表的一组对象通常比由该对象的父类的任何子类所代表的要大得多。 例如， Vehicle 超类包含了所有的交通工具， 如汽车， 卡车， 船， 自行车等。 而 Car 子类仅表示交通工具 Vehicle 中的一个小子集。 继承关系可以用树型层次结构来表示。 一个父类与它的子类的构成层次关系。一个类肯定可以独自存在， 但当一个类是运用了继承的机理时， 这个类要么成为一个提供属性和行为的父类， 要么成为一个继承这些属性和行为的子类。 通常情况下，一个类既是父类也是子类。 一个子类的对象可以被当作其父类的对象来处理。 这使得可能会有一些有趣的操作。 例如， 尽管有从一个特定的父类派生出的众多子类的对象彼此之间可能会有很大的不同的事实， 但只要我们将他们当作父类的对象来看， 我们仍可以创建一个引用的数组给他们。 但反之则不然： 一个父类对象不能被当成一个子类对象。 例如，图形（Shape） 不一定是圆(Circle) 。 尽管子类的对象也“是” 父类的对象， 子类类型和父类类型却是不相同的。 子类对象可以被视为父类的对象。 这是合理的， 因为子类含有和每个超类成员相对应的成员。 但也应认识到， 子类通常拥有比父类更多的成员。 但 Java 不允许逆向赋值， 因为如果把超类对象赋给子类的引用， 就会使子类中额外的子类成员没有定义。 子类对象的引用可以被隐式地转换为超类对象的引用， 因为根据继承性， 子类对象“是” 超类对象。 有四种可能的方法来使父类的对象和子类的对象与父类的引用和子类的引用相匹配： 1、 父类对象与可以直接用父类的引用。 2、 子类对象与可以直接用子类的引用。 3、 子类的对象用父类的引用是安全的， 因为子类对象同样也是其父类的对象。但这样的代码只能引用父类的成员。 如果该代码通过父类的引用来访问子类所特有的成员， 编译器就会报告一个语法错误。 4、 如果用子类来引用父类的对象， 将报告一个语法错误。 尽管将子类的对象看成是父类的对象会带来很大的便利， 而且可以通过这些父类的引用操纵这些对象来实现， 但这会引发一个问题。 在一个工资管理系统， 例如，我们希望能够通过一组员工数组来计算每个人的周薪。 但是直觉告诉人们， 使用父类的引用将使程序只调用父类的工资计算程序（如果父类中确实有这样一个程序的话）。 我们需要一种方式仅通过使用父类的引用来正确的调用对每个对象（无论是父类对象或子类对象） 相对应的工资计算程序。 其实， 这正是当我们考虑了多态性和动态链接后 Java 所呈现的并将在此章节中讨论的内容。 我们可以使用继承来定制现有的软件。 当我们使用继承来从现有类创建一个新类时， 新类将继承的原有类的属性和行为， 此时我们可以添加属性和行为或重载父类的行为来定制能满足我们需要的类。 很难让学生意识到设计师和工业的大型软件项目的实施者所面临的问题。 做过这类项目的人都会说提高软件开发效率的最好方法是鼓励对软件的再利用。 一般来说， 面向对象的编程， 像 Java， 就可以实现。 实质和有用的类库使得通过及继承而实现的软件重用实现利益最大化。 人们对Java 类库的兴趣随着 Java 的发展而增加。 正如独立软件厂商生产的压缩套装的软件伴随着个人电脑的问世而出现爆炸性的增长一样， Java 类库的制造和销售也将呈现这样一个趋势。 应用程序设计人员将使用这些类库来构建他们的应用程序， 而类库的设计者会因为将其开发的类库与应用程序打包在一起而得到收益。 在不久的将来， 随着在大量领域的应用， Java 的类库将会起到至关重要的作用并得到极大的发展。 附件 ２： 外文原文（复印件） Java Object-oriented programming --Object-oriented programming and its key component technologies as inheritance and polymorphism. Software reusability saves time in program development. It encourages reuse of proven and debugged high-quality software, thus reducing

problems after a system becomes operational. These are exciting possibilities. Polymorphism enables us to write programs in a general fashion to handle a wide variety of existing and yet-to-be-specified related classes.Polymorphism makes it easy to add new capabilities to a system. Inheritance and polym-orphism are effective techniques for dealing with software complexity. When creating a new class, instead of writing completely new instance variables and instance methods, the programmer can designate that the new class is to inherit the instance variables and instance methods of a previously defined superclass. The new class is referred to as a subclass. Each subclass itself becomes a candidate to be a superclass for some future subclass. The direct superclass of a class is the superclass from which the class explicitly inherits (via the keyword extends). An indirect superclass is inherited from two or more levels up the class hierarchy. For example, class JApplet (package javax.swing) extends class Applet (package java.applet). With single inheritance, a class is derived from one superclass. Java does not support multiple inheritance (as C++ does) but it does support the notion of interfaces. interfaces help Java achieve many of the advantages of multiple inheritance without the associated problems. We will discuss the details of interfaces in this chapter. We consider both general principles and a detailed specific example of creating and using interfaces. A subclass normally adds instance variables and instance methods of its own, so a subclass is generally larger than its superclass. A subclass is more specific than its superclass and represents a smaller, more specialized group of objects. With single inheritance, the subclass starts out essentially the same as the superclass. The real strength of inheritance comes from the ability to define in the subclass additions to, or replacements for, the features inherited from the superclass. Every subclass object is also an object of that class’s superclass. For example, every applet we have defined is considered to be an object of class JApplet. Also, because JApplet extends Applet, every applet we have defined is considered to be an Applet. This information is critical when developing applets, because an applet container can execute a program only if it is an Applet. Although a subclass object always can be treated as one of its superclass types, superclass objects are not considered to be objects of their subclass types. We will take advantage of this “subclass-object-is-a-superclass-object” relationship to perform some powerful manipulations. For example, a drawing application can maintain a list of shapes to display. If all the shape types extend the same superclass directly or indirectly, the drawing program can store all the shapes in an array (or other data structure) of superclass objects. As we will see in this chapter, this ability to process a set of objects as a single type is a key thrust of object-oriented programming. We add a new form of member access control in this chapter, namely protected access. Subclass methods and methods of other classes in the same package as the superclass can access protected superclass members. Experience in building software systems indicates that significant portions of the code deal with closely related special cases. It becomes difficult in such systems to see the “big picture”because the designer and the programmer become preoccupied with the special cases. Object-oriented programming provides several ways of “seeing the forest through the trees.” The programmer and designer concentrate on the big picture—the commonality among objects in the system—rather than the special cases. This process is called abstraction. If a procedural program has many closely related special cases, then it is common to see switch structures or nested if/else structures that distinguish among the special cases and provide the processing logic to deal with each case individually. We will show how to use inheritance and polymorphism to replace such switch logic with much simpler logic. We distinguish between the “is a” relationship and the “has a” relationship. “Is a” is inheritance.

In an “is a” relationship, an object of a subclass type may also be treated as an object of its superclass type. “Has a” is composition. In a“has a” relationship, a class object has one or more objects of other classes as members. For example, a car has a steering wheel. A subclass’s methods might need to access certain of its superclass’s instance variables and methods. A crucial aspect of software engineering in Java is that a subclass cannot access the private members of its superclass. If a subclass could access the superclass’s private members, this would violate information hiding in the superclass. However, a subclass can access the public and protected members of its superclass. A subclass also can use the package access members of its superclass if the subclass and superclass are in the same package. Superclass members that should not be accessible to a subclass via inheritance are declared private in the superclass. A subclass can effect state changes in superclass private members only through public, protected and package access methods provided in the superclass and inherited into the subclass. A problem with inheritance is that a subclass can inherit methods that it does not need or should not have. It is the class designer’s responsibility to ensure that the capabilities provided by a class are appropriate for future subclasses. Even when the superclass methods are appropriate for the subclasses, it is common for a subclass to require the method to perform a task in a manner that is specific to the subclass. In such cases, the superclass method can be overridden (redefined) in the subclass with an appropriate implementation. Perhaps most exciting is the notion that new classes can inherit from abundant class libraries, such as those provided with the Java API. Organizations develop their own class libraries and can take advantage of other libraries available worldwide. Someday, most software might be constructed from standardized reusable components, just as hardware is often constructed today. This will help meet the challenges of developing the ever more powerful software we will need in the future. Often an object of one class “is an” object of another class as well. A rectangle certainly is a quadrilateral (as are squares, parallelograms and trapezoids). Thus, class Rectangle can be said to inherit from class Quadrilateral. In this context, class Quadrilateral.is a superclass, and class Rectangle is a subclass. A rectangle is a specific type of quadrilateral, but it is incorrect to claim that a quadrilateral is a rectangle (the quadrilateral could be a parallelogram). Inheritance normally produces subclasses with more features than their superclasses, so the terms superclass and subclass can be confusing. There is another way, however, to view these terms that makes perfectly good sense. Because every subclass object “is an”object of its superclass, and because one superclass can have many subclasses, the set of objects represented by a superclass is normally larger than the set of objects represented by any of that superclass’s subclasses. For example, the superclass Vehicle represents in a generic manner all vehicles, such as cars, trucks, boats, bicycles and so on. However, subclass Car represents only a small subset of all the Vehicles in the world. Inheritance relationships form tree-like hierarchical structures. A superclass exists in a hierarchical relationship with its subclasses. A class can certainly exist by itself, but it is when a class is used with the mechanism of inheritance that the class becomes either a superclass that supplies attributes and behaviors to other classes or a subclass that inherits those attributes and behaviors. Frequently, one class is both a subclass and a superclass. An object of a subclass can be treated as an object of its superclass. This makes possible some interesting manipulations. For example, despite the fact that objects of a variety of classes derived from a particular superclass might be quite different from one another, we can create an array of references to them—as long as we treat them as superclass objects. But the reverse is not true: A superclass object cannot always be treated a subclass object. For example,

a Shape is not always a Circle. Despite the fact that a subclass object also “is a” superclass object, the subclass type and the superclass type are different. Subclass objects can be treated as superclass objects. This makes sense because the subclass has members corresponding to each of the superclass members—remember that the subclass normally has more members than the superclass has. Assignment in the other direction is not allowed because assigning a superclass object to a subclass reference would leave the additional subclass members undefined. A reference to a subclass object could be implicitly converted into a reference to a superclass object because a subclass object is a superclass object through inheritance. There are four possible ways to mix and match superclass references and subclass references with superclass objects and subclass objects: 1. Referring to a superclass object with a superclass reference is straightforward. 2. Referring to a subclass object with a subclass reference is straightforward. 3. Referring to a subclass object with a superclass reference is safe, because the subclass object is an object of its superclass as well. Such code can refer only to superclass members. If this code refers to subclass-only members through the superclass reference, the compiler will report a syntax error. 4. Referring to a superclass object with a subclass reference is a syntax error. As convenient as it might be to treat subclass objects as superclass objects, and to do this by manipulating all these objects with superclass references, there appears to be a problem. In a payroll system, for example, we would like to be able to walk through an array of employees and calculate the weekly pay for each person. But intuition suggests that using superclass references would enable the program to call only the superclass payroll calculation routine (if indeed there is such a routine in the superclass). We need a way to invoke the proper payroll calculation routine for each object, whether it is a superclass object or a subclass object, and to do this simply by using the superclass reference. Actually,this is precisely how Java behaves and is discussed in this chapter when we consider polymorphism and dynamic binding. We can use inheritance to customize existing software. When we use inheritance to create a new class from an existing class, the new class inherits the attributes and behaviors of an existing class; then we can add attributes and behaviors or override superclass behaviors to customize the class to meet our needs. It can be difficult for students to appreciate the problems faced by designers and implementers on large-scale software projects in industry. People experienced on such projects will invariably state that a key to improving the software development process is encouraging software reuse. Object-oriented programming in general, and Java in particular, certainly does this. It is the availability of substantial and useful class libraries that delivers the maximum benefits of software reuse through inheritance. As interest in Java grows, interest in Java class libraries will increase. Just as shrink-wrapped software produced by independent software vendors became an explosive growth industry with the arrival of the personal computer, so, too, will the creation and sale of Java class libraries. Application designers will build their applications with these libraries, and library designers will be rewarded by having their libraries wrapped with the applications. What we see coming is a massive worldwide commitment to the development of Java class libraries for a huge variety of applications arenas.