|
|
.NET 4.5中添加了兩個(gè)新的集合接口，IReadOnlyList和IReadOnlyDictionary。盡管這些接口表面上看起來是如此稀松平常，但是他們卻揭露了與向后兼容性、互操作性、以及協(xié)變的作用等有關(guān)的相當(dāng)復(fù)雜的故事。
IReadOnlyList和IReadOnlyDictionary是.NET開發(fā)者自始至終都想得到的接口。只讀接口除了提供某種對稱性之外，還應(yīng)消除那些什么都不做而只拋出NotSupportedException異常的方法。由于某些隨時(shí)間流逝已不可知的原因，此接口并未完成。
接下來一次機(jī)會是在.NET 2.0中引入泛型。這使得微軟可以淘汰弱類型集合，并使用強(qiáng)類型變體替代它們。基類庫[1]團(tuán)隊(duì)再次錯(cuò)過了這個(gè)提供只讀列表（read-only list）的機(jī)會，正如Kit George 所寫的那樣，
因?yàn)閷τ谀闩cJoe所談?wù)摰膯栴}，我們打算提供一種缺省實(shí)現(xiàn)，而不是給你一個(gè)接口，所以我們提供了ReadOnlyCollectionBase基類。然而，鑒于它不是強(qiáng)類型的，我能理解人們不愿使用它的原因。但隨著泛型的引入，我們現(xiàn)在同時(shí)擁有了ReadOnlyCollection<T>，所以你不僅獲得了同等的功能，而且就是強(qiáng)類型的：太棒了！
ReadOnlyCollection<T>不是密封類，因此如果需要可以隨意在此之上編寫你自己的集合。自從我們?yōu)榇藙?chuàng)作的這些集合可適合一般需求以來，我們尚沒有計(jì)劃為與此相同的概念引入接口。
Krzysztof Cwalina也對此主題進(jìn)行了評論，
無論這聽起來令人驚訝與否，但是IList和IList<T>是我們所期望的只讀集合接口。它們都擁有IsReadOnly布爾型屬性，當(dāng)某個(gè)只讀集合實(shí)現(xiàn)此屬性后應(yīng)返回true。我們不想添加純粹的只讀接口的原因是，我們覺得它會給基類庫添加太多不必要的復(fù)雜性。請注意，就復(fù)雜性而言，我們既指此新接口又指其消費(fèi)者。
我們覺得API的設(shè)計(jì)者們要么是并不關(guān)心在運(yùn)行時(shí)檢查IsReadOnly屬性、及其可能拋出的異常，在這種情況下使用IList接口就不錯(cuò)，要么他們愿意提供一個(gè)真正整潔的自定義API，在這種情況下他們應(yīng)顯示實(shí)現(xiàn)IList接口、并公布自定義的簡潔的只讀API。對于從對象模型中公開的集合而言，后者是種典型方式。
盡管開發(fā)曾抱怨此種情況，由于泛型所提供的新機(jī)會遠(yuǎn)遠(yuǎn)大于這個(gè)癥結(jié)，因此該問題在.NET 4以前很大程度上被忽視了。然而，此決定也引發(fā)了一些反響，我們將在稍后討論。
隨著在.NET 4中一個(gè)令人興奮的新功能被添加到運(yùn)行時(shí)。當(dāng)早期版本的.NET接口出現(xiàn)在類型中時(shí)，那些接口是被過度限制的。例如，即使Customer繼承自Person，也無法將類型為IEnumerable<Customer>的對象作為參數(shù)類型為IEnumerable<Person>的函數(shù)的參數(shù)使用。隨著協(xié)變支持的添加，該限制才得以部分解除。
我們之所以說“部分”，是因?yàn)樵谀承┣榫跋拢鄬τ贗Enumerable接口而言，人們更愿意使用一個(gè)具有豐富API的接口。而且當(dāng)IList接口不支持協(xié)變的時(shí)候，至少該有一個(gè)只讀列表接口。不幸的是，.NET基類庫團(tuán)隊(duì)再次決定不解決這個(gè)疏忽。
接著，WinRT的引入和COM的死灰復(fù)燃改變了一切。COM互操作性曾是開發(fā)者在別無選擇的情況下才使用的一種技術(shù)，但現(xiàn)已成為.NET編程的基石。而且由于WinRT公開了IVectorView<T>和IMapView<K, V>接口，因此.NET必須與時(shí)俱進(jìn)。
WinRT計(jì)劃中一個(gè)頗為有趣的功能是，為每個(gè)開發(fā)平臺公布不同但功能類似的API。正如你可能已經(jīng)知道的，通過JavaScript開發(fā)者的眼睛所看到的是，所有方法名都是駝峰式大小寫（camelCased[2]）表示的，而C++和.NET開發(fā)者所看到方法則是以帕斯卡大小寫（PascalCased[3]）表示的。另一處更加劇烈的變化是，在C++與.NET的接口之間實(shí)現(xiàn)自動映射。因此.NET開發(fā)者無需處理Windows.Foundation.Collections命名空間，而是繼續(xù)使用System.Collections.Generic命名空間。IVectorView<T>和IMapView<K, V>這兩個(gè)接口會被運(yùn)行庫轉(zhuǎn)化為IReadOnlyList<T>和IReadOnlyDictionary<TKey, TValue>。
值得注意的是，在C++/WinRT中的這些接口名在某定程度上是更準(zhǔn)確的。這些接口是用來表示針對某集合的一些視圖，但是接口并不確保該集合本身是不可變的。即使在那些經(jīng)驗(yàn)豐富的.NET開發(fā)者中也很常見的一種錯(cuò)誤是，假設(shè)ReadOnlyCollection類型的對象是某個(gè)集合的不可變副本，其實(shí)，事實(shí)上此對象僅僅是對某活動集合的包裝（wrapper）（關(guān)于只讀、凍結(jié)、且不可變集合的詳細(xì)信息，請參閱Andrew Arnott的同名帖子）。
當(dāng)?shù)弥M管IList<T>接口具有與IReadOnlyList<T>接口所有相同的成員、并且所有列表都可表示為只讀列表，而IList<T>卻不是繼承自IReadOnlyList<T>以后，有人可能會覺得很有趣。Immo Landwerth解釋說，
這看起來是個(gè)合理的假設(shè)，它之所以能工作是因?yàn)槟切┲蛔x接口是可讀寫接口的純粹子集。不幸的是，此假設(shè)與預(yù)期不符，因?yàn)樵谠獢?shù)據(jù)級別上位于每個(gè)接口上的每個(gè)方法都有其自己的槽（這使得顯式接口實(shí)現(xiàn)得以工作）。
或者換言之，他們必須將只讀接口作為那些可變種類的基類引入的唯一機(jī)會就是退回到.NET 2.0，即它們最初被構(gòu)思出來的時(shí)候。一旦放虎歸山，對其能做的唯一改變就是添加協(xié)變和/或逆變標(biāo)記（在VB和C#中表示為“in”和“out”）。
當(dāng)被問及為什么沒有IReadOnlyCollection<T>接口時(shí)，Immo回答說，
我們曾考慮過這個(gè)設(shè)計(jì)，但是我們覺得加入一個(gè)提供僅有Count屬性的類型對于基類庫而言不會增加很多價(jià)值。在基類庫團(tuán)隊(duì)中，我們認(rèn)為，如果一個(gè)API從負(fù)1000點(diǎn)開始，那么即使能提供一些價(jià)值也不足以證明可被添加。添加新API的理由也包括成本，例如，開發(fā)者會擁有更多可供選擇的概念。起初我們認(rèn)為，添加這個(gè)類型將使得代碼在某些場景（你只想獲得計(jì)數(shù)，然后對它做一些有趣的東西）下獲得更好的性能。例如，批量添加到現(xiàn)有集合。然而，在這些場景下，我們鼓勵(lì)人們僅采用一個(gè)IEnumerable<T>接口，而且對于擁有實(shí)現(xiàn)了ICollection<T>接口的實(shí)例的特殊情況也是如此。自從所有我們的內(nèi)建集合類型實(shí)現(xiàn)了此接口之后，然而在那些最常見的情況下并未沒有獲得任何性能收益。順便說一下，針對IEnumerable<T>的擴(kuò)展方法Count()同樣可以完成此功能。
這些新接口可用于.NET 4.5和.NET for Windows 8。
譯注
[1] 基類庫，Base Class Library，縮寫為BCL。有關(guān)基類庫的更多信息，請參與MSDN。
[2] camelCased，駝峰式命名法，又稱小駝峰式命名法（lower camel case）。格式為，第一個(gè)單字以小寫字母開始；第二個(gè)單字的首字母大寫，例如：firstName、lastName。
[3] PascalCased，帕斯卡命名法，又稱大駝峰式命名法（upper camel case）。格式為，每一個(gè)單字的首字母都采用大寫字母，例如：FirstName、LastName、CamelCase。
查看英文原文：The Story of Read-Only Collection Interfaces in .NET
NET技術(shù)：.NET 4.5 中只讀集合接口的故事，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。
