java中英文文獻(xiàn).doc

南 京 理 工 大 學(xué) 紫 金 學(xué) 院 畢業(yè)設(shè)計(jì)(論文) 外文資料翻譯 系： 計(jì)算機(jī)系 專 業(yè)： 計(jì)算機(jī)科學(xué)與技術(shù) 姓 名： 學(xué) 號： 外 文 出 處 ：(用外文寫) Ghosh,D.Java Object-oriented programmingJ. IEEE Transactions on Software Engineering,2009, 13(3):42-45. 附 件： 外文資料翻譯譯文； 外文原文。 指導(dǎo)教師評語： 簽名： 年 月 日注： 請將該封面與附件裝訂成冊。 附件 ： 外文資料翻譯譯文 Java 的面向?qū)ο缶幊?面向?qū)ο缶幊毯退年P(guān)鍵技術(shù)繼承和多態(tài)性 軟件的重用可以節(jié)省程序開發(fā)時(shí)間。 它鼓勵(lì)重復(fù)使用已經(jīng)調(diào)試好的高質(zhì)量的軟件， 從而減少系統(tǒng)運(yùn)行后可能出現(xiàn)的問題。 這些都是令人振奮的可能性。 多態(tài)性允許我們用統(tǒng)一的風(fēng)格編寫程序， 來處理多種已存在的類和特定的相關(guān)類。 利用多態(tài)性我們可以方便地向系統(tǒng)中添加新的功能。 繼承和多態(tài)對于解決軟件的復(fù)雜性是一種有效可行的技術(shù)。 當(dāng)創(chuàng)建一個(gè)新的類時(shí)， 而不用完整的寫出新的實(shí)例變量和實(shí)例方法， 程序員會(huì)指定新的類繼承已定義的超類的實(shí)例變量和實(shí)例方法。 這個(gè)新的類被稱為一個(gè)子類。 每個(gè)子類本身將來亦可有新的子類， 而其本身將成為父類。 一個(gè)類的直接父類就是該類所直接繼承的類（通過關(guān)鍵字 extends 繼承）。 一個(gè)間接超類是通過從兩級或更多級以上的類繼承而來的。例如， 從類 JApplet （包 javax. swing中）擴(kuò)展來的類 Applet （包 java. applet）。一個(gè)類單一的從一個(gè)父類繼承而來。 Java不支持多重繼承（而 C+可以）， 但它支持接口的概念。 接口可以使 Java 實(shí)現(xiàn)許多通過多重繼承才能實(shí)現(xiàn)的優(yōu)點(diǎn)而沒有關(guān)聯(lián)的問題。 我們將在本章討論的接口的詳細(xì)內(nèi)容。 我們會(huì)給出創(chuàng)建和使用接口的一般規(guī)律和具體實(shí)例。 一個(gè)子類通常添加自己的實(shí)例變量和自己的實(shí)例方法， 因此子類通常比父類大。 一個(gè)子類比它的父類更具體并且代表一組更小、 更專業(yè)的對象。 通過單一繼承， 子類在開始時(shí)擁有父類的所有特性。 繼承性真正的力量在于它可以在定義子類時(shí)增加或取代從超類中繼承來的特征。 每個(gè)子類對象也是該類的父類的對象。 例如， 每一個(gè)我們所定義的小程序被認(rèn)為是類 JApplet 的對象。 此外， 因?yàn)?Japplet 繼承了 Applet， 每一個(gè)我們所定義的小程序同時(shí)也被認(rèn)為是一個(gè) Applet 的對象。 當(dāng)開發(fā) applets 時(shí)， 這些信息是至關(guān)重要的， 因?yàn)橐粋€(gè)小程序容器只有當(dāng)它是一個(gè) Applet 才可以執(zhí)行一個(gè)程序。雖然子類對象始終可以作為它的父類的一種來看待， 父類對象卻不被認(rèn)為是其子類類型的對象。 我們將利用這種“子類對象是父類對象” 的關(guān)系來執(zhí)行一些強(qiáng)大的操作。 例如， 繪圖程序可以顯示一系列圖形， 如果所有的圖形類型都直接或間接地繼 承同一超類， 繪圖程序就可以將所有圖形存儲在一個(gè)超類對象數(shù)組或其他數(shù)據(jù)結(jié)構(gòu)中。 正如我們將要在這一章中看到的， 這種處理單一類型的一系列的對象的能力是推動(dòng)面向?qū)ο蟪绦虬l(fā)展的重要推動(dòng)力。 我們添加一個(gè)新的成員訪問的一種控制形式protected 訪問。 由同一個(gè)包中子類和其他類的方法組成的父類可以訪問受保護(hù)的父類的成員。 開發(fā)軟件的實(shí)踐經(jīng)驗(yàn)表明， 處理的代碼的重要部分涉及密切相關(guān)的案例。 因?yàn)樵O(shè)計(jì)人員和程序員十分專注于特殊案例， 所以很難在這種系統(tǒng)中看到 “大局”。 面向?qū)ο缶幊烫峁?“透過樹木見森林” 的幾種方法。 程序員和設(shè)計(jì)人員專注于系統(tǒng)中對象的共性而不是特定實(shí)例， 這種方法叫做抽象。 如果一個(gè)程序性方案有許多密切相關(guān)的案例， 那么就會(huì)常用到 switch 交換結(jié)構(gòu)或嵌套的 if / else 結(jié)構(gòu)從而區(qū)分眾多的案例并提供獨(dú)立處理各個(gè)案例的邏輯。我們下面將學(xué)習(xí)如何使用繼承性和多態(tài)性以更簡單的邏輯來代替 switch 結(jié)構(gòu)。 我們區(qū)分“is a” 關(guān)系和“has a” 的關(guān)系。 “is a” 就是繼承。 在 “是” 關(guān)系中，子類類型的對象也可以被看作是它的父類型的對象處理。 “有” 是一種構(gòu)成。 在“有” 關(guān)系中， 一個(gè)類對象有一個(gè)或多個(gè)其它類的對象作為成員。 例如， 車有方向盤。 子類的方法可能需要確切訪問它的父類的實(shí)例變量和方法。 在 Java 中， 軟件工程的一個(gè)至關(guān)重要的方面就是子類不能訪問其父類的私有成員。 如果子類可以訪問父類的私有成員， 這就違背了父類的信息隱蔽原則。 然而， 一個(gè)子類可以訪問它的父類的 public 成員和 protected 成員。 如果子類和父類在同一個(gè)包中， 子類也可以使用它的程序包訪問父類成員。 如果超類不允許通過繼承產(chǎn)生的子類訪問它的某些成員， 則需要用 private 聲明成員。 子類只可以通過公有繼承、 受保護(hù)繼承和程序包借助父類提供的繼承到子類中的方法聲明對父類中私有成員的改變。 繼承會(huì)帶來的問題是， 子類會(huì)將一些沒必要繼承或不該繼承方法也繼承過來。類的編寫者應(yīng)確保由類提供的功能對未來的子類是適用的。 即使父類的方法對子類適用， 子類也可以使該方法來完成特定于子類的方式的任務(wù)。 在這種情況下， 子類可以覆蓋超類的方法， 以提供一種合適的實(shí)現(xiàn)。 也許最令人興奮的是一個(gè)新類可以從豐富的類庫中繼承， 比如 Java API 提供許多類。 一些組織開發(fā)自己的類庫的同時(shí)還具有可以利用現(xiàn)有的全球其他庫的優(yōu)勢。 總有一天， 大多數(shù)的軟件可以通過可重用的標(biāo)準(zhǔn)化的組件來構(gòu)建， 就像現(xiàn)在制造硬件一樣。 這將有助于面對開發(fā)我們將來可能需要的更加強(qiáng)大的軟件的挑戰(zhàn)。 我們常常會(huì)遇到這樣一個(gè)問題， 一個(gè)類的對象同時(shí)還“是” 另一個(gè)類的對象。矩形肯定是一個(gè)四邊形（如同正方形， 平行四邊形和梯形）。 因此， Rectangle 類可以說是從 Quadrilateral 類繼承而來的。 在這種情況下， Quadrilateral 類是父類， Rectangle 類是一個(gè)子類。 矩形是特殊的四邊形， 但卻不能說四邊形就是矩形（四邊形可能是平行四邊形）。 繼承通常能夠產(chǎn)生比其父類具有更多功能的子類， 所以父類和子類的概念很容易引起混淆。 然而， 我們還有另種一更好的方法來區(qū)分這兩個(gè)概念。 因?yàn)槊總€(gè)子類對象也“是” 其父類的對象， 而一個(gè)父類又可以有很多子類， 那么由父類所代表的一組對象通常比由該對象的父類的任何子類所代表的要大得多。 例如， Vehicle 超類包含了所有的交通工具， 如汽車， 卡車， 船， 自行車等。 而 Car 子類僅表示交通工具 Vehicle 中的一個(gè)小子集。 繼承關(guān)系可以用樹型層次結(jié)構(gòu)來表示。 一個(gè)父類與它的子類的構(gòu)成層次關(guān)系。一個(gè)類肯定可以獨(dú)自存在， 但當(dāng)一個(gè)類是運(yùn)用了繼承的機(jī)理時(shí)， 這個(gè)類要么成為一個(gè)提供屬性和行為的父類， 要么成為一個(gè)繼承這些屬性和行為的子類。 通常情況下，一個(gè)類既是父類也是子類。 一個(gè)子類的對象可以被當(dāng)作其父類的對象來處理。 這使得可能會(huì)有一些有趣的操作。 例如， 盡管有從一個(gè)特定的父類派生出的眾多子類的對象彼此之間可能會(huì)有很大的不同的事實(shí)， 但只要我們將他們當(dāng)作父類的對象來看， 我們?nèi)钥梢詣?chuàng)建一個(gè)引用的數(shù)組給他們。 但反之則不然： 一個(gè)父類對象不能被當(dāng)成一個(gè)子類對象。 例如，圖形（Shape） 不一定是圓(Circle) 。 盡管子類的對象也“是” 父類的對象， 子類類型和父類類型卻是不相同的。 子類對象可以被視為父類的對象。 這是合理的， 因?yàn)樽宇惡泻兔總€(gè)超類成員相對應(yīng)的成員。 但也應(yīng)認(rèn)識到， 子類通常擁有比父類更多的成員。 但 Java 不允許逆向賦值， 因?yàn)槿绻殉悓ο筚x給子類的引用， 就會(huì)使子類中額外的子類成員沒有定義。 子類對象的引用可以被隱式地轉(zhuǎn)換為超類對象的引用， 因?yàn)楦鶕?jù)繼承性， 子類對象“是” 超類對象。 有四種可能的方法來使父類的對象和子類的對象與父類的引用和子類的引用相匹配： 1、 父類對象與可以直接用父類的引用。 2、 子類對象與可以直接用子類的引用。 3、 子類的對象用父類的引用是安全的， 因?yàn)樽宇悓ο笸瑯右彩瞧涓割惖膶ο?。但這樣的代碼只能引用父類的成員。 如果該代碼通過父類的引用來訪問子類所特有的成員， 編譯器就會(huì)報(bào)告一個(gè)語法錯(cuò)誤。 4、 如果用子類來引用父類的對象， 將報(bào)告一個(gè)語法錯(cuò)誤。 盡管將子類的對象看成是父類的對象會(huì)帶來很大的便利， 而且可以通過這些父類的引用操縱這些對象來實(shí)現(xiàn)， 但這會(huì)引發(fā)一個(gè)問題。 在一個(gè)工資管理系統(tǒng)， 例如，我們希望能夠通過一組員工數(shù)組來計(jì)算每個(gè)人的周薪。 但是直覺告訴人們， 使用父類的引用將使程序只調(diào)用父類的工資計(jì)算程序（如果父類中確實(shí)有這樣一個(gè)程序的話）。 我們需要一種方式僅通過使用父類的引用來正確的調(diào)用對每個(gè)對象（無論是父類對象或子類對象） 相對應(yīng)的工資計(jì)算程序。 其實(shí)， 這正是當(dāng)我們考慮了多態(tài)性和動(dòng)態(tài)鏈接后 Java 所呈現(xiàn)的并將在此章節(jié)中討論的內(nèi)容。 我們可以使用繼承來定制現(xiàn)有的軟件。 當(dāng)我們使用繼承來從現(xiàn)有類創(chuàng)建一個(gè)新類時(shí)， 新類將繼承的原有類的屬性和行為， 此時(shí)我們可以添加屬性和行為或重載父類的行為來定制能滿足我們需要的類。 很難讓學(xué)生意識到設(shè)計(jì)師和工業(yè)的大型軟件項(xiàng)目的實(shí)施者所面臨的問題。 做過這類項(xiàng)目的人都會(huì)說提高軟件開發(fā)效率的最好方法是鼓勵(lì)對軟件的再利用。 一般來說， 面向?qū)ο蟮木幊蹋?像 Java， 就可以實(shí)現(xiàn)。 實(shí)質(zhì)和有用的類庫使得通過及繼承而實(shí)現(xiàn)的軟件重用實(shí)現(xiàn)利益最大化。 人們對Java 類庫的興趣隨著 Java 的發(fā)展而增加。 正如獨(dú)立軟件廠商生產(chǎn)的壓縮套裝的軟件伴隨著個(gè)人電腦的問世而出現(xiàn)爆炸性的增長一樣， Java 類庫的制造和銷售也將呈現(xiàn)這樣一個(gè)趨勢。 應(yīng)用程序設(shè)計(jì)人員將使用這些類庫來構(gòu)建他們的應(yīng)用程序， 而類庫的設(shè)計(jì)者會(huì)因?yàn)閷⑵溟_發(fā)的類庫與應(yīng)用程序打包在一起而得到收益。 在不久的將來， 隨著在大量領(lǐng)域的應(yīng)用， Java 的類庫將會(huì)起到至關(guān)重要的作用并得到極大的發(fā)展。 附件 ： 外文原文（復(fù)印件） 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 classs 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 picturethe commonality among objects in the systemrather 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 subclasss methods might need to access certain of its superclasss 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 superclasss 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 designers 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 superclasss 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 themas 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 membersremember 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, wheth