Java

Java 1.2添加了自己的一套工具 + 生產力，可用來對數組或列表進行排列和搜尋。這些工具都屬於兩個新類的“靜態”方法。這兩個類分別是用於排序和搜尋數組的Arrays，以及用於排序和搜尋列表的Collections。1. 數組Arrays類為所有基礎資料型別 (Elementary Data

下面這張表格（表一）總結了用一個集合能做的所有事情（亦可對Set和List做同樣的事情，儘管List還提供了一些額外的功能）。Map不是從Collection繼承的，所以要單獨對待。boolean add(Object) ＊保證集合內包含了自變數。如果它沒有添加自變數，就返回false（假）boolean addAll(Collection) ＊添加自變數內的所有元素。如果沒有添加元素，則返回true（真）void clear() ＊刪除集合內的所有元素boolean

寫在前面的話引言:第1章 對象入門1.1 抽象的進步1.2 對象的介面1.3 實現方案的隱藏1.4 方案的重複使用1.5 繼承：重新使用介面1.5.1

通過本章的學習，大家已知道標準Java庫提供了一些特別有用的集合，但距完整意義的集合尚遠。除此之外，象排序這樣的演算法根本沒有提供支援。C++出色的一個地方就是它的庫，特別是“標準模板庫”（STL）提供了一套相當完整的集合，以及許多象排序和檢索這樣的演算法，可以非常方便地對那些集合進行操作。有感這一現狀，並以這個模型為基礎，ObjectSpace公司設計了Java版本的“通用集合庫”（從前叫作“Java通用庫”，即JGL；但

Vector允許我們用一個數字從一系列對象中作出選擇，所以它實際是將數字同對象關聯起來了。但假如我們想根據其他標準選擇一系列對象呢？堆棧就是這樣的一個例子：它的選擇標準是“最後壓入堆棧的東西”。這種“從一系列對象中選擇”的概念亦可叫作一個“映射”、“字典”或者“關聯陣列”。從概念上講，它看起來象一個Vector，但卻不是通過數字來尋找對象，而是用另一個對象來尋找它們！這通常都屬

BitSet實際是由“二進位位”構成的一個Vector。如果希望高效率地儲存大量“開－關”資訊，就應使用BitSet。它只有從尺寸的角度看才有意義；如果希望的高效率的訪問，那麼它的速度會比使用一些固有類型的數組慢一些。此外，BitSet的最小長度是一個長整數（Long）的長度：64位。這意味著假如我們準備儲存比這更小的資料，如8位元據，那麼BitSet就顯得浪費了。所以最好建立自己的類，用它容納自己的標誌位。在一個普通的Vector中，隨我們加入越

Vector的用法很簡單，這已在前面的例子中得到了證明。儘管我們大多數時候只需用addElement()插入對象，用elementAt()一次提取一個對象，並用elements()獲得對序列的一個“枚舉”。但仍有其他一系列方法是非常有用的。同我們對於Java庫慣常的做法一樣，在這裡並不使用或講述所有這些方法。但請務必閱讀相應的電子文檔，對它們的工作有一個大概的認識。1.

在任何集合類中，必須通過某種方法在其中置入對象，再用另一種方法從中取得對象。畢竟，容納各種各樣的對象正是集合的首要任務。在Vector中，addElement()便是我們插入對象採用的方法，而elementAt()是提取對象的唯一方法。Vector非常靈活，我們可在任何時候選擇任何東西，並可使用不同的索引選擇多個元素。若從更高的角度看這個問題，就會發現它的一個缺陷：需要事Crowdsourced Security

使用Java集合的“缺點”是在將對象置入一個集合時丟失了類型資訊。之所以會發生這種情況，是由於當初編寫集合時，那個集合的程式員根本不知道使用者到底想把什麼類型置入集合。若指示某個集合只允許特定的類型，會妨礙它成為一個“常規用途”的工具，為使用者帶來麻煩。為解決這個問題，集合實際容納的是類型為Object的一些對象的控制代碼。這種類型當然代表Java中的所有對象，因為它是所有類的根。當然，也要注意這並不包括基礎資料型別 (Elementary

假定我們現在想寫一個方法，同時不希望它僅僅返回一樣東西，而是想返回一系列東西。此時，象C和C++這樣的語言會使問題複雜化，因為我們不能返回一個數組，只能返回指向數組的一個指標。這樣就非常麻煩，因為很難控制數組的“存在時間”，它很容易造成記憶體“漏洞”的出現。Java採用的是類似的方法，但我們能“返回一個數組”。當然，此時返回的實際仍是指向數組的指標。但在Java裡，我們永遠不必擔心那個數組的是否可用—&mdash

■《Java in a Nutshell:A Desktop Quick Reference，第2版》作者：David Flanagan出版社：O'Reilly & Assoc出版時間：1997簡介：對Java 1.1聯機文檔的一個簡要總結。就個人來說，我更喜歡線上閱覽文檔，特別是在它們變化得如此快的時候。然而，許多人仍然喜歡印刷出來的文檔，這樣可以省一些上網費。而且這本書也提供了比聯機文檔更多的討論。■《The Java Class Libraries:An Annotated

由於我們在上溯造型（在繼承結構中向上移動）期間丟失了具體的類型資訊，所以為了擷取具體的類型資訊——亦即在分級結構中向下移動——我們必須使用

學習繼承時，為了建立繼承分級結構，看來最明顯的方法是採取一種“純粹”的手段。也就是說，只有在基礎類或“介面”中已建立的方法才可在衍生類中被覆蓋，如下面這張圖所示：可將其描述成一種純粹的“屬於”關係，因為一個類的介面已規定了它到底“是什麼”或者“屬於什麼”。通過繼承，可保證所有衍生類都只擁有基礎類的介面。如果按上述示意圖操作，衍生出來的類除了基礎類的介面之外，也不會再擁有其他什麼

通過“合成”方法建立新類時，永遠不必擔心對那個類的成員對象的收尾工作。每個成員都是一個獨立的對象，所以會得到正常的垃圾收集以及收尾處理——無論它是不是不自己某個類一個成員。但在進行初始化的時候，必須覆蓋衍生類中的finalize()方法——如果已經設計了某個特殊的清除進程，要求它必須作為垃圾收集的一部分進行。覆蓋衍生類的finalize()時，務必記住調用finalize()的基礎類版本。否則，基礎類的初始化根本不會發生。下

由於每個類都會產生一個.class檔案，用於容納與如何建立這個類型的對象有關的所有資訊（這種資訊產生了一個名為Class對象的元類），所以大家或許會猜到內部類也必鬚生成相應的.class檔案，用來容納與它們的Class對象有關的資訊。這些檔案或類的名字遵守一種嚴格的形式：先是封裝類的名字，再跟隨一個$，再跟隨內部類的名字。例如，由InheritInner.java建立的.class檔案包括：InheritInner.classWithInner$Inner.classWithInner.clas

若建立一個內部類，然後從封裝類繼承，並重新定義內部類，那麼會出現什麼情況呢？也就是說，我們有可能覆蓋一個內部類嗎？這看起來似乎是一個非常有用的概念，但“覆蓋”一個內部類——好象它是外部類的另一個方法——這一概念實際不能做任何事情： //: BigEgg.java// An inner class cannot be overriden // like a methodclass Egg { protected

為正確理解static在應用於內部類時的含義，必須記住內部類的對象預設持有建立它的那個封裝類的一個對象的控制代碼。然而，假如我們說一個內部類是static的，這種說法卻是不成立的。static內部類意味著：(1) 為建立一個static內部類的對象，我們不需要一個外部類對象。(2)

迄今為止，我們見到的內部類好象僅僅是一種名字隱藏以及程式碼群組織方案。儘管這些功能非常有用，但似乎並不特別引人注目。然而，我們還忽略了另一個重要的事實。建立自己的內部類時，那個類的對象同時擁有指向封裝對象（這些對象封裝或產生了內部類）的一個連結。所以它們能訪問那個封裝對象的成員——毋需取得任何資格。除此以外，內部類擁有對封裝類所有元素的存取權限（注釋②）。下面這個例子闡示了這個問題： //: Sequence.java// Holds a sequence

至此，我們已基本理解了內部類的典型用途。對那些涉及內部類的代碼，通常表達的都是“單純”的內部類，非常簡單，且極易理解。然而，內部類的設計非常全面，不可避免地會遇到它們的其他大量用法——假若我們在一個方法甚至一個任意的範圍內建立內部類。有兩方面的原因促使我們這樣做：(1) 正如前面展示的那樣，我們準備實現某種形式的介面，使自己能建立和返回一個控制代碼。(2)

在Java