【正文】 s another issue, however, and that39。答案是肯定的，我們可以采用 “ 參數(shù)化類型 ” ，它們是編譯器能自動定制的類，可與特定的類型配合。這種造型方法叫 “ 下溯造型 ” （ Downcasting）。單根結(jié)構意味著、所有東西歸根結(jié)底都是一個 “ 對象 ” ！所以容納了 Object 的一個集合實際可以容納任何東西。與此有關的必要支持可安裝于基礎類中，而垃圾收集器可將適當?shù)南l(fā)給系統(tǒng)內(nèi)的任何對象。需添加我們要用到的各種新類庫，還要使用另一些不兼容的接口。甚至可以想象有一個 “ 完美 ” 的集合抽象，它能根據(jù)自己的使用方式自動改變基層的實現(xiàn)方式。這些以及其他操作都有不同的執(zhí)行效率，具體取決于序列的基礎結(jié)構是什么。 其次，不同的集合在進行特定操作時往往有不同的效率。 Java 新增一個更復雜的集合庫，其中包含了一個名為 Iterator的繼承器，可以做比老式的 Enumeration3 更多的事情。此外，單選定 函數(shù)的功能是非常有限的。所以我們能根據(jù)自己的需要選擇適當?shù)念愋?。只需?chuàng)建一個集合，以后的工作讓它自己負責好了。既然如此，怎樣才能知道那些對象要求多少空間呢？事先上根本無法提前知道，除非進入運行期。 但還要考慮另外一個問題，亦即對象的 “ 存在時間 ” 或者 “ 生存時間 ”（ Lifetime）。若采用這種方式，除非進入運行期 ，否則根本不知道到底需要多少個對象，也不知道它們的存在時間有多長，以及準確的類型是什么。對象需要的數(shù)據(jù)位于哪兒，如何控制對象的 “ 存在時間 ” 呢？針對這個問題，解決的方案是各異其趣的。 C++認為程序的執(zhí)行效率是最重要的一個問題，所以它允許程序員 做出 選擇。這些參數(shù)都在程序正式運行時才決定的。若在堆?；蛘哽o態(tài)存儲空間里創(chuàng)建一個對象，編譯器會判斷對象的持續(xù)時間有多長，到時會自動 “ 破壞 ” 或者 “ 清除 ” 它。 在面向?qū)ο蟮脑O計中，大多數(shù)問題的解決辦法似乎都有些輕率 ——只是簡單地創(chuàng)建另一種類型的對象。 幸運的是，設計優(yōu)良的 OOP 語言都配套提供了一系列集合。其中包括集、隊列、散列表、樹、堆棧等等。如果想對集合中的一系列元素進行操縱或比較，而不是僅僅面向一個，這時又該怎么辦呢？ 辦法就是使用一個 “ 繼續(xù)器 ” （ Iterator），它屬于一種對象，負責選擇集合內(nèi)的元素，并把它們提供給繼承器的用戶。 從設計角度出發(fā)，我們需要的是一個全功能的序列。最好的例子便是矢量（ Vector）和列表（ List）的區(qū)別。在設計階段，我們可以先從一個列表開始。 單根結(jié)構 在面向?qū)ο蟮某绦蛟O計中，由于 C++的引入而顯得尤為突出的一個問題是：所有類最終是否都應從單獨一個基礎類繼承。理所 當然地，這也需要付出額外的精力使新接口與自己的設計方案配合（可能還需要多重繼承）。如果沒有這種單根結(jié)構，而且系統(tǒng)通過一個句柄來操縱對象，那么實現(xiàn)垃圾收集器的途徑會有很大的不同，而且會面臨許多障礙。這使我們對它的重復使用變得非常簡便。舉個例子來說，我們知道在上溯造型的時候， Circle（圓）屬于 Shape（幾何形狀）的一種類型，所以上溯造型是安全的。例如，通過使用一個參數(shù)化集合，編譯器可對那個集合進行定制，使其只接受 Shape，而且只提取 Shape。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 7 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 iterators If 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 solves this particular problem holds references to other objects. Of course, you can do the same thing with an array, which is available in most languages. But there’s more. This new object, generally called a container (also called a collection, but the Java library uses that term in a different sense so this book will use “container”), will expand itself whenever necessary to acmodate everything you place inside it. So you don’t need to know how manyobjects you’re going to hold in a container. Just create a container object and let it take care of the details. Fortunately, a good OOP language es with a set of containers as part of the package. In C++, it’s part of the Standard C++ Library and is sometimes called the Standard Template Library (STL). Object Pascal has containers in its Visual Component Library (VCL). Smalltalk has a very plete set of containers. Java also has containers in its standard library. In some libraries, a generic container is considered good enough for all needs, and in others (Java, for example) the library has differ