java基础系列:集合基础(2)
集合的類型
V e c t o r
崩潰 Java
Java 標準集合里包含了 toString()方法,所以它們能生成自己的 String 表達方式,包括它們容納的對象。
例如在 Vector 中, toString()會在 Vector 的各個元素中步進和遍歷,并為每個元素調用 toString()。假定我們現在想打印出自己類的地址。看起來似乎簡單地引用 this 即可(特別是 C++程序員有這樣做的傾向):
此時發生的是字串的自動類型轉換。當我們使用下述語句時:
“CrashJava address: ” + this
編譯器就在一個字串后面發現了一個“ +”以及好象并非字串的其他東西,所以它會試圖將 this 轉換成一個字串。轉換時調用的是 toString(),后者會產生一個遞歸調用。若在一個 Vector 內出現這種事情,看起來堆棧就會溢出,同時違例控制機制根本沒有機會作出響應。
若確實想在這種情況下打印出對象的地址,解決方案就是調用 Object 的 toString 方法。此時就不必加入this,只需使用 super.toString()。當然,采取這種做法也有一個前提:我們必須從 Object 直接繼承,或者沒有一個父類覆蓋了 toString 方法。
B i t S e t
BitSet 實際是由“ 二進制位”構成的一個 Vector。如果希望高效率地保存大量“開-關”信息,就應使用BitSet。它只有從尺寸的角度看才有意義;如果希望的高效率的訪問,那么它的速度會比使用一些固有類型的數組慢一些。
BitSet 的最小長度是一個長整數( Long)的長度: 64 位。這意味著假如我們準備保存比這更小的數據,如 8 位數據,那么 BitSet 就顯得浪費了。所以最好創建自己的類,用它容納自己的標志位。
S t a c k
Stack 有時也可以稱為“后入先出”( LIFO)集合。換言之,我們在堆棧里最后“壓入”的東西將是以后第
一個“彈出”的。和其他所有 Java 集合一樣,我們壓入和彈出的都是“對象”,所以必須對自己彈出的東西
進行“造型”。
下面是一個簡單的堆棧示例,它能讀入數組的每一行,同時將其作為字串壓入堆棧。
months 數組的每一行都通過 push()繼承進入堆棧,稍后用 pop()從堆棧的頂部將其取出。要聲明的一點是,Vector 操作亦可針對 Stack 對象進行。這可能是由繼承的特質決定的—— Stack“屬于”一種 Vector。因此,能對 Vector 進行的操作亦可針對 Stack 進行,例如 elementAt()方法
H a s h t a b l e
Vector 允許我們用一個數字從一系列對象中作出選擇,所以它實際是將數字同對象關聯起來了。
但假如我們想根據其他標準選擇一系列對象呢?堆棧就是這樣的一個例子:它的選擇標準是“最后壓入堆棧的東西”。
這種“從一系列對象中選擇”的概念亦可叫作一個“映射”、“字典”或者“關聯數組”。從概念上講,它看起來象一個 Vector,但卻不是通過數字來查找對象,而是用另一個對象來查找它們!這通常都屬于一個程序中的重要進程。
在 Java 中,這個概念具體反映到抽象類 Dictionary 身上。該類的接口是非常直觀的 size()告訴我們其中包含了多少元素; isEmpty()判斷是否包含了元素(是則為 true); put(Object key, Object value)添加一個值(我們希望的東西),并將其同一個鍵關聯起來(想用于搜索它的東西); get(Object key)獲得與某個鍵對應的值;而 remove(Object Key)用于從列表中刪除“鍵-值”對。還可以使用枚舉技術: keys()產生對鍵的一個枚舉( Enumeration);而 elements()產生對所有值的一個枚舉。這便是一個 Dict ionary(字典)的全部。
在對 AssocArray 的定義中,我們注意到的第一個問題是它“擴展”了字典。這意味著 AssocArray 屬于Dictionary 的一種類型,所以可對其發出與 Dictionary 一樣的請求。如果想生成自己的 Dictionary,而且就在這里進行,那么要做的全部事情只是填充位于 Dictionary 內的所有方法(而且必須覆蓋所有方法,因為
它們—— 除構建器外—— 都是抽象的)。
標準 Java 庫只包含 Dictionary 的一個變種,名為 Hashtable(散列表,注釋③)。 Java 的散列表具有與AssocArray 相同的接口(因為兩者都是從 Dictionary 繼承來的)。但有一個方面卻反映出了差別:執行效率。若仔細想想必須為一個 get()做的事情,就會發現在一個 Vector 里搜索鍵的速度要慢得多。但此時用散列表卻可以加快不少速度。不必用冗長的線性搜索技術來查找一個鍵,而是用一個特殊的值,名為“散列碼”。散列碼可以獲取對象中的信息,然后將其轉換成那個對象“相對唯一”的整數( int)。所有對象都有一個散列碼,而 hashCode()是根類 Object 的一個方法。 Hashtable 獲取對象的 hashCode(),然后用它快速查找鍵。
- 創建“關鍵”類
但在使用散列表的時候,一旦我們創建自己的類作為鍵使
用,就會遇到一個很常見的問題。例如,假設一套天氣預報系統將Groundhog(土拔鼠)對象匹配成Prediction(預報) 。這看起來非常直觀:我們創建兩個類,然后將Groundhog 作為鍵使用,而將Prediction 作為值使用。如下所示:
問題在于Groundhog 是從通用的 Object 根類繼承的(若當初未指
定基礎類,則所有類最終都是從 Object 繼承的)。事實上是用 Object 的 hashCode()方法生成每個對象的散列碼,而且默認情況下只使用它的對象的地址。所以, Groundhog(3)的第一個實例并不會產生與Groundhog(3)第二個實例相等的散列碼,而我們用第二個實例進行檢索
或許認為此時要做的全部事情就是正確地覆蓋 hashCode()。但這樣做依然行不能,除非再做另一件事情:覆蓋也屬于 Object 一部分的 equals()。當散列表試圖判斷我們的鍵是否等于表內的某個鍵時,就會用到這個方法。同樣地,默認的 Object.equals()只是簡單地比較對象地址,所以一個 Groundhog(3)并不等于
另一個 Groundhog(3)。
因此,為了在散列表中將自己的類作為鍵使用,必須同時覆蓋 hashCode()和 equals(),就象下面展示的那樣:
Groundhog2.hashCode()將土拔鼠號碼作為一個標識符返回(在這個例子中,程序員需要保證沒有兩個土拔鼠用同樣的 ID 號碼并存)。為了返回一個獨一無二的標識符,并不需要 hashCode(), equals()方法必須能夠嚴格判斷兩個對象是否相等。
equals()方法要進行兩種檢查:檢查對象是否為 null;若不為 null ,則繼續檢查是否為 Groundhog2 的一個實例(要用到 instanceof 關鍵字)。即使為了繼續執行 equals(),它也應該是一個Groundhog2。正如大家看到的那樣,這種比較建立在實際 ghNumber 的基礎上。這一次一旦我們運行程序,就會看到它終于產生了正確的輸出(許多 Java 庫的類都覆蓋了 hashcode() 和 equals()方法,以便與自己提供的內容適應)。
再論枚舉器
將穿越一個序列的操作與那個序列的基礎結構分隔開。在下面的例子里, PrintData 類用一個 Enumeration 在一個序列中移動,并為每個對象都調用toString()方法。此時創建了兩個不同類型的集合:一個 Vector 和一個 Hashtable。并且在它們里面分別填
充 Mouse 和 Hamster 對象,由于 Enumeration 隱藏了基層集合的結構,所以PrintData 不知道或者不關心 Enumeration 來自于什么類型的集合:
注意 PrintData.print()利用了這些集合中的對象屬于 Object 類這一事實,所以它調用了 toString()。但在
解決自己的實際問題時,經常都要保證自己的 Enumeration 穿越某種特定類型的集合。例如,可能要求集合
中的所有元素都是一個 Shape(幾何形狀),并含有 draw()方法。若出現這種情況,必須從
Enumeration.nextElement()返回的 Object 進行下溯造型,以便產生一個 Shape。
排序
編寫通用的排序代碼時,面臨的一個問題是必須根據對象的實際類型來執行比較運算,從而實現正確的排序。當然,一個辦法是為每種不同的類型都寫一個不同的排序方法。然而,應認識到假若這樣做,以后增加新類型時便不易實現代碼的重復利用。
程序設計一個主要的目標就是“將發生變化的東西同保持不變的東西分隔開”。在這里,保持不變的代碼是通用的排序算法,而每次使用時都要變化的是對象的實際比較方法。因此,我們不可將比較代碼“硬編碼”到多個不同的排序例程內,而是采用“回調”技術。
利用回調,經常發生變化的那部分代碼會封裝到它自己的類內,而總是保持相同的代碼則“回調”發生變化的代碼。這樣一來,不同的對象就可以表達不同的比較方式,同時向它們傳遞相同的排序代碼。
下面這個“接口”( Interface)展示了如何比較兩個對象,它將那些“要發生變化的東西”封裝在內:
對這兩種方法來說, lhs 代表本次比較中的“左手”對象,而 rhs 代表“右手”對象。
可創建 Vector 的一個子類,通過 Compare 實現“快速排序”。對于這種算法,包括它的速度以及原理等等
為使用 SortVector,必須創建一個類,令其為我們準備排序的對象實現 Compare。此時內部類并不顯得特別重要,但對于代碼的組織卻是有益的。下面是針對 String 對象的一個例子
public class StringSortTest {static class StringCompare implements Compare {public boolean lessThan(Object l, Object r) {return ((String) l).toLowerCase().compareTo(((String) r).toLowerCase()) < 0;}public boolean lessThanOrEqual(Object l, Object r) {return ((String) l).toLowerCase().compareTo(((String) r).toLowerCase()) <= 0;}}public static void main(String[] args) {SortVector sv = new SortVector(new StringCompare());sv.addElement("d");sv.addElement("A");sv.addElement("C");sv.addElement("c");sv.addElement("b");sv.addElement("B");sv.addElement("D");sv.addElement("a");sv.sort();Enumeration e = sv.elements();while (e.hasMoreElements())System.out.println(e.nextElement());} }一旦設置好框架,就可以非常方便地重復使用象這樣的一個設計—— 只需簡單地寫一個類,將“需要發生變化”的東西封裝進去,然后將一個對象傳給SortVector 即可
繼承( extends)在這兒用于創建一種新類型的 Vector—— 也就是說, SortVector 屬于一種 Vector,并帶有一些附加的功能。繼承在這里可發揮很大的作用,但了帶來了問題。它使一些方法具有了final 屬性,所以不能覆蓋它們。如果想創建一個排好序的 Vector,令其只接收和生成 String 對象,就會遇到麻煩。因為 addElement()和 elementAt()都具有 final 屬性,而且它們都是我們必須覆蓋的方法,否則便無法實現只能接收和產生 String 對象。
但在另一方面,請考慮采用“合成”方法:將一個對象置入一個新類的內部。此時,不是改寫上述代碼來達到這個目的,而是在新類里簡單地使用一個 SortVector。在這種情況下,用于實現 Compare 接口的內部類就可以“匿名”地創建
總結
以上是生活随笔為你收集整理的java基础系列:集合基础(2)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: java基础系列:集合基础(1)
- 下一篇: java基础系列:集合基础(3)