.NET 2.0 基礎(chǔ)類庫中的范型——范型集合
2024-07-10 12:59:30
供稿：網(wǎng)友
范型集合
毫無疑問，范型最典型的應(yīng)用莫過于范型集合了。在 .net 2.0 中提供了已有集合類和接口的范型版本，它們位于 system.collections.generic 命名空間中。
.net 2.0 中新的范型集合類并不是簡單的在已有非范型集合類的設(shè)計(jì)上多加了個(gè)范型參數(shù) t 而已。新的范型集合類的設(shè)計(jì)充分吸收了已有設(shè)計(jì)中的合理之處并摒棄了一些不甚合理之處，同時(shí)引入了新的針對范型的設(shè)計(jì)。所以，新的范型類和接口的設(shè)計(jì)應(yīng)該更加合理和有效，不過 .net 程序員則需要花些時(shí)間學(xué)習(xí)新的設(shè)計(jì)并了解與已有設(shè)計(jì)有什么樣的不同，以及在將代碼從非范型集合移植到范型集合時(shí)可能會(huì)出現(xiàn)的兼容性問題。
下面是范型集合和已有非范型集合的對照表（不全）：
非范型接口
范型接口
非范型類
范型類
ienumerator
ienumerator<t>
arraylist
list<t>
ienumerable
ienumerable<t>
stack
stack<t>
icollection
icollection<t>
queue
queue<t>
ilist
ilist<t>
dictionaryentry
keyvaluepair<k, v>
idictionary
idictionary<t>
hashtable
dictionary<k, v>
icomparable
icomparable<t>
comparer
comparer<t>
icomparer
icomparer<t>
可以看到，部分類的名字做了修改，例如 arraylist 現(xiàn)在改為 list<t>，hashtable 改為 dictionary<k, v>，dictionaryentry 改為 keyvaluepair<k, v> 等等。這樣的命名當(dāng)然更加合理（因?yàn)?ilist<t> 是接口，list<t> 是對應(yīng)的具體類；同樣 idictionary<k, v> 是接口， dictionary<k, v> 是對應(yīng)的具體類；而 keyvaluepair<k, v> 顯然比 dictionaryentry 更加容易理解和記憶），但對已經(jīng)習(xí)慣了以前的命名的程序員來說可能一開始會(huì)有點(diǎn)找不找北的感覺。
前面說過，新的范型集合接口/類和以前的非范型版本相比有較大的設(shè)計(jì)改變，下面我們來看看這些變化。
ienumerator<t>
ienumerator/ienumerator<t> 接口允許對一個(gè)集合進(jìn)行遍歷，主要用在 .net 編程語言的遍歷語句中，例如 c# 的 foreach 語句。用戶代碼通常不直接使用這個(gè)接口。ienumerator<t> 和非范型版本 ienumerator 相比去掉了 reset 方法。這可能是出于以下考慮：
l ienumerator<t> 接口主要設(shè)計(jì)用于支持諸如 foreach 這樣的語句，而這些地方用不到 reset 方法。去掉 reset 方法使得設(shè)計(jì)更加簡化并降低了實(shí)現(xiàn)該接口的難度。如果調(diào)用者需要類似 reset 的功能，可以重新獲取一個(gè)枚舉器（例如通過調(diào)用 getenumerator 方法）。
l c# 2.0 iterators 提供了自動(dòng)生成枚舉器的方法，編譯器自動(dòng)為指定的類實(shí)現(xiàn) ienumerator 接口和 ienumerator<t> 接口。而對ienumerator 接口的 reset 方法的實(shí)現(xiàn)只是簡單的拋出 system.notsupportedexception 異常。所以在 ienumerator<t> 的設(shè)計(jì)中移去 reset 方法顯得非常自然和合理。
icollection<t>
icollection<t> 接口的設(shè)計(jì)和非范型版本 icollection 相比改變很大。icollection 接口的最初設(shè)計(jì)意圖是支持復(fù)制集合元素（通過 count 屬性和 copyto 方法），以及支持同步訪問模式（通過 issynchronized 屬性和 syncroot 屬性）。icollection<t> 的設(shè)計(jì)保留了對復(fù)制集合元素的支持，但是摒棄了對同步訪問模式的支持，這是因?yàn)閷?shí)踐證明 icollection 的同步訪問模式是讓人困惑和低效的。不少剛學(xué) .net 的程序員一開始搞不懂 syncroot 是個(gè)什么東東，有什么用。另外，從性能和邏輯上考慮，何時(shí)鎖定集合應(yīng)該由調(diào)用者決定，而不是由實(shí)現(xiàn)者決定。所以總的來說 issynchronized 和 syncroot 不是很理想的設(shè)計(jì)。因此，icollection<t> 沒有 issynchronized 屬性和 syncroot 屬性。
除此之外，icollection<t> 還增加了一些新的屬性和方法，它們讓 icollection<t> 接口變得更加有用。這些屬性和方法事實(shí)上是從 ilist 和 idictionary 的共同屬性和方法移植過來的，包括：
l isreadonly，用于判斷集合是否是只讀的。
l add/remove/clear，用于對集合元素進(jìn)行管理。這些方法對列表和字典都是有效的。
l contains，用于判斷集合中是否包含指定的值。
另外，對于一些不需要更改集合的使用情景來說，提供一個(gè)類似 ireadonlycollection<t> 這樣的接口可能會(huì)有意義，它只需要支持 count 屬性，copyto 方法和 contains 方法即可。然而微軟并沒有采用這樣的設(shè)計(jì)，主要理由是為了使基本集合接口盡量簡單和易用。微軟的建議是程序員需要的話自己定義這樣的接口。
ilist<t> 和 list<t>
剛才提到，ilist<t> 相對于 ilist 的變化是通用的屬性和方法被移植入 icollection<t> 了，僅剩下對列表有效的基于索引訪問的屬性和方法。
list<t> 相對 arraylist 來講也做了很大的設(shè)計(jì)改變。做出這些改變的主要考慮是性能，因?yàn)閯?dòng)態(tài)數(shù)組是 .net 程序使用的最基本的數(shù)據(jù)結(jié)構(gòu)之一，它的性能影響到應(yīng)用程序的全局。例如，以前 arraylist 默認(rèn)的 capacity 是 16，而 list<t> 的默認(rèn) capacity 是 4，這樣可以盡量減小應(yīng)用程序的工作集。另外，list<t> 的方法不是虛擬方法（arraylist 的方法是虛擬方法），這樣可以利用函數(shù)內(nèi)聯(lián)來提高性能（虛函數(shù)不可以被內(nèi)聯(lián)）。list<t> 也不支持問題多多的 synchronized 同步訪問模式。
list<t> 相比 arraylist 增加的一個(gè)重要特性則是對 functional programming 的支持。我們將在 functional programming 部分介紹這一新特性。
idictionary<k, v> 和 dictionary<k, v>
idictionary<k, v> 和 dictionary<k, v> 相比非范型版本一個(gè)很大的變化是當(dāng)指定的鍵不存在時(shí)索引器的處理邏輯。對 idictionary 和 hashtable 來說，值的存儲(chǔ)類型是 object，當(dāng)鍵不存在時(shí)，索引器將返回 null，當(dāng)鍵存在而對應(yīng)值為 null 的話也返回 null（設(shè)計(jì)者可能認(rèn)為調(diào)用者通常關(guān)心的是值是不是有效，而不是區(qū)分這兩種情況）。然而，對于范型版本來說，因?yàn)榇鎯?chǔ)的可能是值類型，所以不可以返回 null 來作為鍵不存在的標(biāo)識(shí)。因此， idictionary<k, v>和 dictionary<k, v> 的索引器在指定鍵不存在的情況下將拋出 keynotfoundexception 異常。這將導(dǎo)致源代碼級別的不兼容，也就是說，以下的代碼在存儲(chǔ)值類型的情況下將不可移植，而必須改寫（例如先使用 containskey 方法判斷指定鍵是否存在，然后再訪問；或者使用不拋出異常的 trygetvalue 方法）：
hashtable map = ...;
if (map[“s1”] == null) { // 如果是范型版本將拋出異常而不是返回null
...
}
這一問題反映了設(shè)計(jì)者在最初設(shè)計(jì) hashtable 類的時(shí)候考慮的并不是很周到——使用了魔術(shù)值 null，既可以是指鍵不存在的情況，也可以是鍵存在而值為 null 的情況，而這一點(diǎn)對范型是不成立的。另外，從 design by contract 的角度講，當(dāng)指定鍵值不存在時(shí)，拋出異常是很自然的事情（與是否使用范型無關(guān)），就像數(shù)組越界一樣。估計(jì)原設(shè)計(jì)者主要是從性能角度考慮才使用了 null 而不是異常處理。
icomparable<t>，icomparer<t> 和comparer<t>
這幾個(gè)接口/類用于比較和排序。icomparable<t> 相比 icomparable 添加了 equals 方法，當(dāng)然也是為了盡量減少 boxing（對于值類型類說）。icomparer<t> 相對 icomparer 則不僅添加了 equals 方法，而且還新增加了 gethashcode 方法。咋看一下似乎和比較不太相關(guān)，但事實(shí)上，對于字符串來說，比較和哈希值是息息相關(guān)的。在以前的非范型設(shè)計(jì)中，需要同時(shí)使用 icomparer 和 ihashcodeprovider 兩個(gè)接口，例如 hashtable 的構(gòu)造函數(shù)：
public hashtable(ihashcodeprovider hcp, icomparer comparer);
其中 ihashcodeprovider 和 icomparer 兩個(gè)參數(shù)必須匹配（例如都使用 invariantcultureignorecase），否則結(jié)果會(huì)不正確。為了讓程序員能夠快速的編寫出正確的代碼，現(xiàn)在的 icomparer<t> 把比較和生成哈希代碼的功能集成在一起，例如 dictionary<k, v> 的構(gòu)造函數(shù)：
public dictionary(icomparer<k, v> comparer);
comparer<k, v> 提供了 icomparer<k, v> 的默認(rèn)實(shí)現(xiàn)，微軟最新的設(shè)計(jì)指南建議使用 comparer<k, v> 而不是其他方法來比較和排序。
另外，.net 2.0 中新添加了一個(gè)字符串比較類——stringcomparer，位于 system 命名空間。stringcomparer 不是一個(gè)范型類，不過它實(shí)現(xiàn)了 icomparer<string> 接口，對于需要提供大小寫無關(guān)的字符串比較很有用。例如，下面的代碼創(chuàng)建了一個(gè)大小寫無關(guān)的字典：
dictionary<string, int> dict = new dictionary<string, int>(stringcomparer.invariantcultureignorecase);
dict[“test”] = 10;
int n = dict[“test”];
注冊會(huì)員，創(chuàng)建你的web開發(fā)資料庫，
