【正文】 Java采取的這種關(guān)鍵字保留機(jī)制其實(shí)經(jīng)常讓人摸不著頭腦，很難斷定以后會(huì)發(fā)生什么事情。參數(shù)化類(lèi)型是C++一個(gè)重要的組成部分，這部分是C++沒(méi)有單根結(jié)構(gòu)的緣故。下溯造型和運(yùn)行期檢查都要求花額外的時(shí)間來(lái)運(yùn)行程序，而且程序員必須付出額外的精力。但我們不知道一個(gè)Object到底是Circle還是Shape，所以很難保證下溯造型的安全進(jìn)行，除非確切地知道自己要操作的是什么。但這一次不是在分級(jí)結(jié)構(gòu)中上溯造型成一種更“通用”的類(lèi)型。為使用這樣的一個(gè)集合，只需添加指向它的對(duì)象句柄即可，以后可以通過(guò)句柄重新使用對(duì)象。Java提供了這樣的一個(gè)庫(kù)，盡管它在Java （Java ）。由于運(yùn)行期的類(lèi)型信息肯定存在于所有對(duì)象中，所以永遠(yuǎn)不會(huì)遇到判斷不出一個(gè)對(duì)象的類(lèi)型的情況。一個(gè)單根結(jié)構(gòu)，加上所有對(duì)象都在內(nèi)存堆中創(chuàng)建，可以極大簡(jiǎn)化參數(shù)的傳遞（這在C++里是一個(gè)復(fù)雜的概念）。為得到C++額外的“靈活性”，付出這樣的代價(jià)值得嗎？當(dāng)然，如果真的需要——如果早已是C專(zhuān)家，如果對(duì)C有難舍的情結(jié)——那么就真的很值得。從向后兼容的角度看，這一方案可與C模型更好地配合，而且可以認(rèn)為它的限制更少一些。在Java中（與其他幾乎所有OOP語(yǔ)言一樣），對(duì)這個(gè)問(wèn)題的答案都是肯定的，而且這個(gè)終級(jí)基礎(chǔ)類(lèi)的名字很簡(jiǎn)單，就是一個(gè)“Object”。如果在一個(gè)編程環(huán)境中工作，它由于其他因素（比如在Windows下運(yùn)行，或者由垃圾收集器帶來(lái)了開(kāi)銷(xiāo)）產(chǎn)生了內(nèi)在的開(kāi)銷(xiāo)，那么矢量和鏈接列表之間在系統(tǒng)開(kāi)銷(xiāo)上的差異就或許不是一個(gè)大問(wèn)題。最后調(diào)整性能的時(shí)候，再根據(jù)情況把它換成矢量。而且假設(shè)某個(gè)元素位于列表較遠(yuǎn)的地方，找到它所需的時(shí)間也會(huì)長(zhǎng)許多。它們都屬于簡(jiǎn)單的序列，擁有完全一致的接口和外部行為。堆棧的接口與行為與隊(duì)列的不同，而隊(duì)列的接口與行為又與一個(gè)集（Set）或列表的不同。通過(guò)對(duì)它的操縱，應(yīng)該能解決自己的問(wèn)題。這樣一來(lái)，我們就可以靈活地改變基礎(chǔ)數(shù)據(jù)，不會(huì)對(duì)程序里的代碼造成干擾。作為一個(gè)類(lèi)，它也提供了一級(jí)抽象。如果是一個(gè)數(shù)組形式的實(shí)體，比如一個(gè)矢量（Vector），那么也許能用索引運(yùn)算符或函數(shù)。所有集合都提供了相應(yīng)的讀寫(xiě)功能。在某些庫(kù)中，一個(gè)常規(guī)集合便可滿足人們的大多數(shù)要求；而在另一些庫(kù)中（特別是C++的庫(kù)），則面向不同的需求提供了不同類(lèi)型的集合。在C++中，它們是以“標(biāo)準(zhǔn)模板庫(kù)”（STL）的形式提供的。在需要的時(shí)候，集合會(huì)自動(dòng)擴(kuò)充自己，以便適應(yīng)我們?cè)谄渲兄萌氲娜魏螙|西。用于解決特定問(wèn)題的新型對(duì)象容納了指向其他對(duì)象的句柄。本節(jié)剩下的部分將討論操縱對(duì)象時(shí)要考慮的另一些因素。程序員可用兩種方法來(lái)破壞一個(gè)對(duì)象：用程序化的方式?jīng)Q定何時(shí)破壞對(duì)象，或者利用由運(yùn)行環(huán)境提供的一種“垃圾收集器”特性，自動(dòng)尋找那些不再使用的對(duì)象，并將其清除。C++允許我們決定是在寫(xiě)程序時(shí)創(chuàng)建對(duì)象，還是在運(yùn)行期間創(chuàng)建，這種控制方法更加靈活。若需一個(gè)新對(duì)象，只需在需要它的時(shí)候在內(nèi)存堆里簡(jiǎn)單地創(chuàng)建它即可。如果要解決的是一個(gè)較常規(guī)的問(wèn)題，如計(jì)算機(jī)輔助設(shè)計(jì)、倉(cāng)儲(chǔ)管理或者空中交通控制，這一方法就顯得太局限了。為獲得最快的運(yùn)行速度，存儲(chǔ)以及存在時(shí)間可在編寫(xiě)程序時(shí)決定，只需將對(duì)象放置在堆棧（有時(shí)也叫作自動(dòng)或定域變量）或者靜態(tài)存儲(chǔ)區(qū)域即可。本節(jié)將就這些問(wèn)題進(jìn)行探討。s another issue, however, and that39。外文資料Object landscapes and lifetimesTechnically, OOP is just about abstract data typing, inheritance, and polymorphism, but other issues can be at least as important. The remainder of this section will cover these issues. One of the most important factors is the way objects are created and destroyed. Where is the data for an object and how is the lifetime of the object controlled? There are different philosophies at work here. C++ takes the approach that control of efficiency is the most important issue, so it gives the programmer a choice. For maximum runtime speed, the storage and lifetime can be determined while the program is being written, by placing the objects on the stack (these are sometimes called automatic or scoped variables) or in the static storage area. This places a priority on the speed of storage allocation and release, and control of these can be very valuable in some situations. However, you sacrifice flexibility because you must know the exact quantity, lifetime, and type of objects while you39。s the lifetime of an object. With languages that allow objects to be created on the stack, the piler determines how long the object lasts and can automatically destroy it. However, if you create it on the heap the piler has no knowledge of its lifetime. In a language like C++, you must determine programmatically when to destroy the object, which can lead to memory leaks if you don’t do it correctly (and this is a mon problem in C++ programs). Java provides a feature called a garbage collector that automatically discovers when an object is no longer in use and destroys it. A garbage collector is much more convenient because it reduces the number of issues that you must track and the code you must write. More important, the garbage collector provides a much higher level of insurance against the insidious problem of memory leaks (which has brought many a C++ project to its knees). The rest of this section looks at additional factors concerning object lifetimes and landscapes. 1 Collections and iteratorsIf you don’t know how many objects you’re going to need to solve a particular problem, or how long they will last, you also don’t know how to store those objects. How can you know how much space to create for those objects? You can’t, since that information isn’t known until runtime. The solution to most problems in objectoriented design seems flippant: you create another type of object. The new type of object that so