BT

您是否属于早期采用者或者创新人士?InfoQ正在努力为您设计更多新功能。了解更多

.NET中只读集合接口的故事

| 作者 Jonathan Allen 关注 137 他的粉丝 ,译者 高翌翔 关注 0 他的粉丝 发布于 2011年11月18日. 估计阅读时间: 9 分钟 | ArchSummit社交架构图谱:Facebook、Snapchat、Tumblr等背后的核心技术

.NET 4.5中添加了两个新的集合接口,IReadOnlyList和IReadOnlyDictionary。尽管这些接口表面上看起来是如此稀松平常,但是它们却暴露出关于向后兼容性、互操作性、以及协变的作用等相当复杂的故事。

IReadOnlyList和IReadOnlyDictionary是.NET开发者一直都想得到的两个接口。一个只读接口除了提供某种(相对于可写入接口的)对称感之外,还应消除实现那些只抛出NotSupportedException异常而什么都不做的方法。由于时间原因,这一切未能完成。

接下来一次机会是在.NET 2.0中引入泛型。这使得微软可以淘汰弱类型集合,并使用强类型的对等集合替代之。但是,基类库[1]团队又一次错过了这次提供只读列表(read-only list)的机会,正如Kit George所写到的

由于我们打算为你与Joe所谈论的问题提供一种缺省实现,而不是给出一个接口,因此我们提供了ReadOnlyCollectionBase基类。然而,我能理解人们之所以不愿使用它,是因为它不是强类型的。但随着泛型的引入,我们现在还拥有了ReadOnlyCollection<T>,这样你不仅获得了同等功能,而且还是强类型的:太棒了!

由于ReadOnlyCollection<T>不是密封类,因此必要时你可以开足马力随意编写你自己的集合。因为我们为此创作的这些集合可适应一般需求,所以我们尚未计划为与此相同的概念引入接口。

Krzysztof Cwalina也对此主题发表了看法,

无论这听起来是否令人惊讶,但是IList和IList<T>是我们打算用于只读集合的两个接口。它们都拥有IsReadOnly布尔型属性,当某个只读集合实现此属性后应返回true。我们不想添加纯只读接口的原因是,我们觉得它会给基类库添加太多不必要的复杂性。请注意,就复杂性而言,我们既指此新接口又指其消费者。

我们认为,如果API设计者不关心在运行时检查IsReadOnly属性、及其可能抛出的异常,那么这种情况下使用IList接口并无大碍;如果他们愿意一次性地提供一个真正干净的自定义API,那么这种情况下他们应显示实现IList接口、并公布量身定制的只读API。对于从对象模型中公开的集合而言,后者是种典型方式。

虽然开发者曾抱怨此种情况,但是泛型所提供的新机会远远大于这个症结,并且该问题在.NET 4以前很大程度上被忽视了。然而,此决定也引发了一些反应,我们会在稍后讨论。

随着在.NET 4中一个令人兴奋的新功能被添加到运行时。在较早版本的.NET中,当接口成为类型时,那些接口是受到过分限制的。例如,即使Customer继承自Person,也无法将类型为IEnumerable<Customer>的对象作为参数传给某个参数类型为IEnumerable<Person>的函数。随着协变支持的添加,该限制才得以部分解除。

我们之所以说“部分”,是因为在某些情况下,人们应一次性地使用某个具有丰富API的接口,而不是使用IEnumerable接口。即使IList接口不是协变的,一个只读列表接口也理应如此。不幸的是,.NET基类库团队再次决定不解决此疏忽。

然后,WinRT的引入和COM的卷土重来改变了一切。COM互操作性曾是开发者在别无其他选择的情况下才会使用的一种技术,但现已成为.NET编程的基石。而且由于WinRT公开了IVectorView<T>IMapView<K, V>接口,因此.NET也必须作出相应调整。

WinRT计划中一个颇为有趣的功能是,为每个开发平台公布不同但功能类似的API。正如你可能已经知道的,通过JavaScript开发者眼睛看到的是,所有方法名都表示为驼峰式大小写(camelCased[2]),而C++和.NET开发者看到的方法名则表示为帕斯卡大小写(PascalCased[3])。另一处更加剧烈的变化是,在C++与.NET的接口之间实现自动映射。因此.NET开发者无需处理Windows.Foundation.Collections命名空间,只要继续使用System.Collections.Generic命名空间就行了。IVectorView<T>和IMapView<K, V>这两个接口会被运行库分别转化为IReadOnlyList<T>接口和IReadOnlyDictionary<TKey, TValue>接口。

值得注意的是,在C++/WinRT中的这些接口名在某定程度上是更准确的。这些接口是用来表示针对某集合的一些视图,但是接口并不确保该集合本身是不变的。即使在那些经验丰富的.NET开发者中也很常见的一种错误是,假设ReadOnlyCollection类型是某个不变集合副本,其实,它只是对某个活动集合的包装(wrapper)(关于只读、冻结、且不变集合的详细信息,请参阅Andrew Arnott的同名帖子)。

尽管IList<T>接口与IReadOnlyList<T>接口具有全部相同的成员、并且所有IList<T>类型的列表都可表示为只读列表,但是IList<T>不是继承自IReadOnlyList<T>,当有人得知这些以后可能会觉得很有趣。Immo Landwerth解释说

之所以能工作是因为那些只读接口是可读写接口的纯子集,这看起来是个合理的假设。不幸的是,此假设与实际不符,因为在元数据级别上位于每个接口上的每个方法都有各自的槽(slot)(这使得显式接口实现得以工作)。

或者换言之,引入只读接口作为某些可变种类基类的唯一机会是退回到.NET 2.0,即它们最初被构思出来的时候。一旦全面推出,对其能做的唯一改变就是添加协变和/或逆变标记(在VB和C#中表示为“in”和“out”)。

当被问及为什么没有IReadOnlyCollection<T>接口时,Immo回答说,

我们曾考虑过这个设计,但是我们觉得加入一个提供仅有Count属性的类型并不会为基类库增加太多价值。在基类库团队中,我们认为,如果某个API是从负1000点开始的,那么即使能提供一些价值也不足以证明可被添加。添加新API的理由还包括代价,例如,开发者会拥有更多可供选择的概念。起初我们认为,添加这个类型将使得代码在某些场景(你只想获得计数,然后对它做一些有趣的东西)下获得更好的性能。例如,批量添加到某个现有集合。然而,在这些场景下,我们已鼓励人们仅采用IEnumerable<T>接口,而且对于拥有实现了ICollection<T>接口的实例的特殊情况也是如此。自从我们所有的内建集合类型实现了此接口以后,在那些最常见场景下并未获得任何性能收益。顺便说一下,针对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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

翻译够烂 by jn nemo

话都不通,什么乱七八糟

Re: 翻译够烂——感谢评论,已重新审校发布,请指正! by 高 翌翔

如题。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT