【正文】 畢業(yè)設(shè)計(jì) (論文 ) 外文文獻(xiàn)翻譯 專業(yè) 學(xué) 生 姓 名 班級(jí) 學(xué)號(hào) 指 導(dǎo) 教 師 信息工程學(xué)院 1 中文譯文 對(duì)象的創(chuàng)建和存在時(shí)間 從技術(shù)角度說， OOP（面向?qū)ο蟪绦蛟O(shè)計(jì)）只是涉及抽象的數(shù)據(jù)類型、繼承以及多形性，但另一些問題也可能顯得非常重要。本節(jié)將就這些問題進(jìn)行探討。 最重要的問題之一是對(duì)象的創(chuàng)建及破壞方式。對(duì)象需要的數(shù)據(jù)位于哪兒，如何控制對(duì)象的 “ 存在時(shí)間 ” 呢？針對(duì)這個(gè)問題，解決的方案是各異其趣的。 C++認(rèn)為程序的執(zhí)行效率是最重要的一個(gè)問題，所以它允許程序員 做出 選擇。為獲 得最快的運(yùn)行速度，存儲(chǔ)以及存在時(shí)間可在編寫程序時(shí)決定，只需將對(duì)象放置在堆棧（有時(shí)也叫自動(dòng)或定域變量）或者靜態(tài)存儲(chǔ)區(qū)域即可。這樣便為存儲(chǔ)空間的分配和釋放提供了一個(gè)優(yōu)先級(jí)。某些情況下，這種優(yōu)先級(jí)的控制是非常有價(jià)值的。然而，我們同時(shí)也犧牲了靈活性，因?yàn)樵诰帉懗绦驎r(shí)，必須知道對(duì)象的準(zhǔn)確的數(shù)量、存在時(shí)間、以及類型。如果要解決的是一個(gè)較常規(guī)的問題，如計(jì)算機(jī)輔助設(shè)計(jì)、倉儲(chǔ)管理或者空中交通控制，這一方法就顯得太局限了。 第二個(gè)方法是在一個(gè)內(nèi)存池中動(dòng)態(tài)創(chuàng)建對(duì)象，該內(nèi)存池亦叫 “ 堆 ” 或者 “ 內(nèi)存堆 ” 。若采用這種方式，除非進(jìn)入運(yùn)行期 ，否則根本不知道到底需要多少個(gè)對(duì)象，也不知道它們的存在時(shí)間有多長，以及準(zhǔn)確的類型是什么。這些參數(shù)都在程序正式運(yùn)行時(shí)才決定的。若需一個(gè)新對(duì)象，只需在需要它的時(shí)候在內(nèi)存堆里簡單地創(chuàng)建它即可。由于存儲(chǔ)空間的管理是運(yùn)行期間動(dòng)態(tài)進(jìn)行的，所以在內(nèi)存堆里分配存儲(chǔ)空間的時(shí)間比在堆棧里創(chuàng)建的時(shí)間長得多（在堆棧里創(chuàng)建存儲(chǔ)空間一般只需要一個(gè)簡單的指令，將堆棧指針向下或向下移動(dòng)即可）。由于動(dòng)態(tài)創(chuàng)建方法使對(duì)象本來就傾向于復(fù)雜，所以查找存儲(chǔ)空間以及釋放它所需的額外開銷不會(huì)為對(duì)象的創(chuàng)建造成明顯的影響。除此以外，更大的靈活性對(duì)于常規(guī)編程問 題的解決是至關(guān)重要的。 C++允許我們決定是在寫程序時(shí)創(chuàng)建對(duì)象，還是在運(yùn)行期間創(chuàng)建，這種控制方法更加靈活。大家或許認(rèn)為既然它如此靈活，那么無論如何都應(yīng)在內(nèi)存堆里創(chuàng)建對(duì)象，而不是在堆棧中創(chuàng)建。 但還要考慮另外一個(gè)問題，亦即對(duì)象的 “ 存在時(shí)間 ” 或者 “ 生存時(shí)間 ”（ Lifetime）。若在堆?；蛘哽o態(tài)存儲(chǔ)空間里創(chuàng)建一個(gè)對(duì)象，編譯器會(huì)判斷對(duì)象的持續(xù)時(shí)間有多長，到時(shí)會(huì)自動(dòng) “ 破壞 ” 或者 “ 清除 ” 它。程序員可用兩種方法來破壞一個(gè)對(duì)象：用程序化的方式?jīng)Q定何時(shí)破壞對(duì)象，或者利用由運(yùn)行環(huán)境提供的一種 “ 垃圾收集器 ” 特性，自動(dòng)尋找那些不 再使用的對(duì)象，并將其清除。當(dāng)然，垃圾收集器顯得方便得多，但要求所有應(yīng)用程序都必須容忍垃圾收集器的存在，并能默許隨垃圾收集帶來的額外開銷。但這并不符合 C++語言的設(shè)計(jì)宗旨，所以未能包括到 C++里。但 Java 確實(shí)提供了一個(gè)垃圾收集器（ Smalltalk 也有這樣的設(shè)計(jì)；盡管 Delphi 默認(rèn)為沒有垃圾收集器，但可選擇安裝；而 C++亦可使用一2 些由其他公司開發(fā)的垃圾收集產(chǎn)品）。 本節(jié)剩下的部分將討論操縱對(duì)象時(shí)要考慮的另一些因素。 集合與繼承器 針對(duì)一個(gè)特定問題的解決，如果事先不知道需要多少個(gè)對(duì)象，或者它們的持續(xù)時(shí)間 有多長，那么也不知道如何保存那些對(duì)象。既然如此，怎樣才能知道那些對(duì)象要求多少空間呢？事先上根本無法提前知道，除非進(jìn)入運(yùn)行期。 在面向?qū)ο蟮脑O(shè)計(jì)中，大多數(shù)問題的解決辦法似乎都有些輕率 ——只是簡單地創(chuàng)建另一種類型的對(duì)象。用于解決特定問題的新型對(duì)象容納了指向其他對(duì)象的句柄。當(dāng)然，也可以用數(shù)組來做同樣的事情，那是大多數(shù)語言都具有的一種功能。但不能只看到這一點(diǎn)。這種新對(duì)象通常叫 “ 集合 ” （亦叫一個(gè) “ 容器 ” ，但 AWT在不同的場合應(yīng)用了這個(gè)術(shù)語，所以本書將一直沿用 “ 集合 ” 的稱呼。在需要的時(shí)候，集合會(huì)自動(dòng)擴(kuò)充自己，以便適應(yīng)我 們在其中置入的任何東西。所以我們事先不必知道要在一個(gè)集合里容下多少東西。只需創(chuàng)建一個(gè)集合，以后的工作讓它自己負(fù)責(zé)好了。 幸運(yùn)的是，設(shè)計(jì)優(yōu)良的 OOP 語言都配套提供了一系列集合。在 C++中，它們是以 “ 標(biāo)準(zhǔn)模板庫 ” （ STL）的形式提供的。 Object Pascal 用自己的 “ 可視組件庫 ” （ VCL）提供集合。 Smalltalk 提供了一套非常完整的集合。而 Java 也用自己的標(biāo)準(zhǔn)庫提供了集合。在某些庫中，一個(gè)常規(guī)集合便可滿足人們的大多數(shù)要求；而在另一些庫中（特別是 C++的庫），則面向不同的需求提供了不同類型的集合。例如， 可以用一個(gè)矢量統(tǒng)一對(duì)所有元素的訪問方式；一個(gè)鏈接列表則用于保證所有元素的插入統(tǒng)一。所以我們能根據(jù)自己的需要選擇適當(dāng)?shù)念愋?。其中包括集、?duì)列、散列表、樹、堆棧等等。 所有集合都提供了相應(yīng)的讀寫功能。將某樣?xùn)|西置入集合時(shí)，采用的方式是十分明顯的。有一個(gè)叫 “ 推 ” （ Push）、 “ 添加 ” （ Add）或其他類似名字的函數(shù)用于做這件事情。但將數(shù)據(jù)從集合中取出的時(shí)候，方式卻并不總是那么明顯。如果是一個(gè)數(shù)組形式的實(shí)體，比如一個(gè)矢量（ Vector），那么也許能用索引運(yùn)算符或函數(shù)。但在許多情況下，這樣做往往會(huì)無功而返。此外，單選定 函數(shù)的功能是非常有限的。如果想對(duì)集合中的一系列元素進(jìn)行操縱或比較，而不是僅僅面向一個(gè)，這時(shí)又該怎么辦呢？ 辦法就是使用一個(gè) “ 繼續(xù)器 ” （ Iterator），它屬于一種對(duì)象，負(fù)責(zé)選擇集合內(nèi)的元素，并把它們提供給繼承器的用戶。作為一個(gè)類，它也提供了一級(jí)抽象。利用這一級(jí)抽象，可將集合細(xì)節(jié)與用于訪問那個(gè)集合的代碼隔離開。通過繼承器的作用，集合被抽象成一個(gè)簡單的序列。繼承器允許我們遍歷那個(gè)序列，同時(shí)毋需關(guān)心基礎(chǔ)結(jié)構(gòu)是什么 ——換言之，不管它是一個(gè)矢量、一個(gè)鏈接列表、一個(gè)堆棧，還是其他什么東西。這樣一來，我們就可以靈活地改 變基礎(chǔ)數(shù)據(jù)，不會(huì)對(duì)程序里的代碼造成干擾。 Java 最開始（在 和 版中）提供的是一個(gè)標(biāo)準(zhǔn)繼承器，名為 Enumeration（枚舉），為它的所有集合類提供服務(wù)。 Java 新增一個(gè)更復(fù)雜的集合庫，其中包含了一個(gè)名為 Iterator的繼承器，可以做比老式的 Enumeration3 更多的事情。 從設(shè)計(jì)角度出發(fā)，我們需要的是一個(gè)全功能的序列。通過對(duì)它的操縱，應(yīng)該能解決自己的問題。如果一種類型的序列即可滿足我們的所有要求，那么完全沒有必要再換用不同的類型。有兩方面的原因促使我們需要對(duì)集合 做出 選擇。首先，集合提 供了不同的接口類型以及外部行為。堆棧的接口與行為與隊(duì)列的不同，而隊(duì)列的接口與行為又與一個(gè)集（ Set）或列表的不同。利用這個(gè)特征，我們解決問題時(shí)便有更大的靈活性。 其次，不同的集合在進(jìn)行特定操作時(shí)往往有不同的效率。最好的例子便是矢量（ Vector）和列表（ List）的區(qū)別。它們都屬于簡單的序列，擁有完全一致的接口和外部行為。但在執(zhí)行一些特定的任務(wù)時(shí)，需要的開銷卻是完全不同的。對(duì)矢量內(nèi)的元素進(jìn)行的隨機(jī)訪問（存?。┦且环N常時(shí)操作；無論我們選擇的選擇是什么，需要的時(shí)間量都是相同的。但在一個(gè)鏈接列表中，若想到處移動(dòng)， 并隨機(jī)挑選一個(gè)元素，就需付出 “ 慘重 ” 的代價(jià)。而且假設(shè)某個(gè)元素位于列表較遠(yuǎn)的地方，找到它所需的時(shí)間也會(huì)長許多。但在另一方面，如果想在序列中部插入一個(gè)元素，用列表就比用矢量劃算得多。這些以及其他操作都有不同的執(zhí)行效率，具體取決于序列的基礎(chǔ)結(jié)構(gòu)是什么。在設(shè)計(jì)階段，我們可以先從一個(gè)列表開始。最后調(diào)整性能的時(shí)候，再根據(jù)情況把它換成矢量。由于抽象是通過繼承器進(jìn)行的，所以能在兩者方便地切換，對(duì)代碼的影響則顯得微不足道。 最后，記住集合只是一個(gè)用來放置對(duì)象的儲(chǔ)藏所。如果那個(gè)儲(chǔ)藏所能滿足我們的所有需要，就完全沒必要關(guān)心它具體 是如何實(shí)現(xiàn)的（這是大多數(shù)類型對(duì)象的一個(gè)基本概念）。如果在一個(gè)編程環(huán)境中工作，它由于其他因素（比如在 Windows下運(yùn)行，或者由垃圾收集器帶來了開銷）產(chǎn)生了內(nèi)在的開銷，那么矢量和鏈接列表之間在系統(tǒng)開銷上的差異就或許不是一個(gè)大問題。我們可能只需要一種類型的序列。甚至可以想象有一個(gè) “ 完美 ” 的集合抽象，它能根據(jù)自己的使用方式自動(dòng)改變基層的實(shí)現(xiàn)方式。 單根結(jié)構(gòu) 在面向?qū)ο蟮某绦蛟O(shè)計(jì)中，由于 C++的引入而顯得尤為突出的一個(gè)問題是：所有類最終是否都應(yīng)從單獨(dú)一個(gè)基礎(chǔ)類繼承。在 Java 中（與其他幾乎所有 OOP語言一樣）， 對(duì)這個(gè)問題的答案都是肯定的，而且這個(gè)終級(jí)基礎(chǔ)類的名字很簡單，就是一個(gè) “ Object” 。這種 “ 單根結(jié)構(gòu) ” 具有許多方面的優(yōu)點(diǎn)。 單根結(jié)構(gòu)中的所有對(duì)象都有一個(gè)通用接口，所以它們最終都屬于相同的類型。另一種方案（就 像 C++那樣）是我們不能保證所有東西都屬于相同的基本類型。從向后兼容的角度看，這一方案可與 C 模型更好地配合，而且可以認(rèn)為它的限制更少一些。但假期我們想進(jìn)行純粹的面向?qū)ο缶幊蹋敲幢仨殬?gòu)建自己的結(jié)構(gòu)，以期獲得與內(nèi)建到其他 OOP 語言里的同樣的便利。需添加我們要用到的各種新類庫，還要使用另一些不兼容的接口。理所 當(dāng)然地，這也需要付出額外的