.NET 4.5中添加了兩個新的集合接口，IReadOnlyList和IReadOnlyDictionary。盡管這些接口表面上看起來是如此稀松平常，但是他們卻揭露了與向后兼容性、互操作性、以及協(xié)變的作用等有關的相當復雜的故事。

　　IReadOnlyList和IReadOnlyDictionary是.NET開發(fā)者自始至終都想得到的接口。只讀接口除了提供某種對稱性之外，還應消除那些什么都不做而只拋出NotSupportedException異常的方法。由于某些隨時間流逝已不可知的原因，此接口并未完成。

　　接下來一次機會是在.NET 2.0中引入泛型。這使得微軟可以淘汰弱類型集合，并使用強類型變體替代它們。基類庫^[1]團隊再次錯過了這個提供只讀列表（read-only list）的機會，正如Kit George 所寫的那樣，

因為對于你與Joe所談論的問題，我們打算提供一種缺省實現(xiàn)，而不是給你一個接口，所以我們提供了ReadOnlyCollectionBase基類。然而，鑒于它不是強類型的，我能理解人們不愿使用它的原因。但隨著泛型的引入，我們現(xiàn)在同時擁有了ReadOnlyCollection<T>，所以你不僅獲得了同等的功能，而且就是強類型的：太棒了！

ReadOnlyCollection<T>不是密封類，因此如果需要可以隨意在此之上編寫你自己的集合。自從我們?yōu)榇藙?chuàng)作的這些集合可適合一般需求以來，我們尚沒有計劃為與此相同的概念引入接口。

　　Krzysztof Cwalina也對此主題進行了評論，

無論這聽起來令人驚訝與否，但是IList和IList<T>是我們所期望的只讀集合接口。它們都擁有IsReadOnly布爾型屬性，當某個只讀集合實現(xiàn)此屬性后應返回true。我們不想添加純粹的只讀接口的原因是，我們覺得它會給基類庫添加太多不必要的復雜性。請注意，就復雜性而言，我們既指此新接口又指其消費者。

我們覺得API的設計者們要么是并不關心在運行時檢查IsReadOnly屬性、及其可能拋出的異常，在這種情況下使用IList接口就不錯，要么他們愿意提供一個真正整潔的自定義API，在這種情況下他們應顯示實現(xiàn)IList接口、并公布自定義的簡潔的只讀API。對于從對象模型中公開的集合而言，后者是種典型方式。

　　盡管開發(fā)曾抱怨此種情況，由于泛型所提供的新機會遠遠大于這個癥結，因此該問題在.NET 4以前很大程度上被忽視了。然而，此決定也引發(fā)了一些反響，我們將在稍后討論。

　　隨著在.NET 4中一個令人興奮的新功能被添加到運行時。當早期版本的.NET接口出現(xiàn)在類型中時，那些接口是被過度限制的。例如，即使Customer繼承自Person，也無法將類型為IEnumerable<Customer>的對象作為參數(shù)類型為IEnumerable<Person>的函數(shù)的參數(shù)使用。隨著協(xié)變支持的添加，該限制才得以部分解除。

　　我們之所以說“部分”，是因為在某些情景下，相對于IEnumerable接口而言，人們更愿意使用一個具有豐富API的接口。而且當IList接口不支持協(xié)變的時候，至少該有一個只讀列表接口。不幸的是，.NET基類庫團隊再次決定不解決這個疏忽。

　　接著，WinRT的引入和COM的死灰復燃改變了一切。COM互操作性曾是開發(fā)者在別無選擇的情況下才使用的一種技術，但現(xiàn)已成為.NET編程的基石。而且由于WinRT公開了IVectorView<T>和IMapView<K, V>接口，因此.NET必須與時俱進。

　　WinRT計劃中一個頗為有趣的功能是，為每個開發(fā)平臺公布不同但功能類似的API。正如你可能已經知道的，通過JavaScript開發(fā)者的眼睛所看到的是，所有方法名都是駝峰式大小寫（camelCased^[2]）表示的，而C++和.NET開發(fā)者所看到方法則是以帕斯卡大小寫（PascalCased^[3]）表示的。另一處更加劇烈的變化是，在C++與.NET的接口之間實現(xiàn)自動映射。因此.NET開發(fā)者無需處理Windows.Foundation.Collections命名空間，而是繼續(xù)使用System.Collections.Generic命名空間。IVectorView<T>和IMapView<K, V>這兩個接口會被運行庫轉化為IReadOnlyList<T>和IReadOnlyDictionary<TKey, TValue>。

　　值得注意的是，在C++/WinRT中的這些接口名在某定程度上是更準確的。這些接口是用來表示針對某集合的一些視圖，但是接口并不確保該集合本身是不可變的。即使在那些經驗豐富的.NET開發(fā)者中也很常見的一種錯誤是，假設ReadOnlyCollection類型的對象是某個集合的不可變副本，其實，事實上此對象僅僅是對某活動集合的包裝（wrapper）（關于只讀、凍結、且不可變集合的詳細信息，請參閱Andrew Arnott的同名帖子）。

　　當?shù)弥M管IList<T>接口具有與IReadOnlyList<T>接口所有相同的成員、并且所有列表都可表示為只讀列表，而IList<T>卻不是繼承自IReadOnlyList<T>以后，有人可能會覺得很有趣。Immo Landwerth解釋說，

這看起來是個合理的假設，它之所以能工作是因為那些只讀接口是可讀寫接口的純粹子集。不幸的是，此假設與預期不符，因為在元數(shù)據級別上位于每個接口上的每個方法都有其自己的槽（這使得顯式接口實現(xiàn)得以工作）。

　　或者換言之，他們必須將只讀接口作為那些可變種類的基類引入的唯一機會就是退回到.NET 2.0，即它們最初被構思出來的時候。一旦放虎歸山，對其能做的唯一改變就是添加協(xié)變和/或逆變標記（在VB和C#中表示為“in”和“out”）。

　　當被問及為什么沒有IReadOnlyCollection<T>接口時，Immo回答說，

我們曾考慮過這個設計，但是我們覺得加入一個提供僅有Count屬性的類型對于基類庫而言不會增加很多價值。在基類庫團隊中，我們認為，如果一個API從負1000點開始，那么即使能提供一些價值也不足以證明可被添加。添加新API的理由也包括成本，例如，開發(fā)者會擁有更多可供選擇的概念。起初我們認為，添加這個類型將使得代碼在某些場景（你只想獲得計數(shù)，然后對它做一些有趣的東西）下獲得更好的性能。例如，批量添加到現(xiàn)有集合。然而，在這些場景下，我們鼓勵人們僅采用一個IEnumerable<T>接口，而且對于擁有實現(xiàn)了ICollection<T>接口的實例的特殊情況也是如此。自從所有我們的內建集合類型實現(xiàn)了此接口之后，然而在那些最常見的情況下并未沒有獲得任何性能收益。順便說一下，針對IEnumerable<T>的擴展方法Count()同樣可以完成此功能。

　　這些新接口可用于.NET 4.5和.NET for Windows 8。

　　譯注

　　[1] 基類庫，Base Class Library，縮寫為BCL。有關基類庫的更多信息，請參與MSDN。

　　[2] camelCased，駝峰式命名法，又稱小駝峰式命名法（lower camel case）。格式為，第一個單字以小寫字母開始；第二個單字的首字母大寫，例如：firstName、lastName。

　　[3] PascalCased，帕斯卡命名法，又稱大駝峰式命名法（upper camel case）。格式為，每一個單字的首字母都采用大寫字母，例如：FirstName、LastName、CamelCase。

　　查看英文原文：The Story of Read-Only Collection Interfaces in .NET

NET技術：.NET 4.5 中只讀集合接口的故事，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。