是否每个.NET中的集合类型都应该实现所有.NET类型接口?_最新动态_新闻资讯_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 新闻资讯 > 最新动态 > 是否每个.NET中的集合类型都应该实现所有.NET类型接口?

是否每个.NET中的集合类型都应该实现所有.NET类型接口?

 2015/1/28 17:44:06    程序员俱乐部  我要评论(0)
  • 摘要:英文原文:Shouldall.NETCollectionsImplementall.NETCollectionInterfaces?是否每个.NET中的集合类型都应该实现所有.NET类型接口?在1月14日进行的.NET核心API审查视频中,这一问题在API相关的重要问题中居首位。这段视频录制了针对.NET基础类库的十个变更请求的相关讨论。[视频]GitHubIssue:#316:为正则集合(包括CaptureCollection、GroupCollection和MatchCollection
  • 标签:.net 实现 net 接口 集合类
class="topic_img" alt=""/>

  英文原文: Should all .NET Collections Implement all .NET Collection Interfaces?

  是否每个 .NET 中的集合类型都应该实现所有 .NET 类型接口?在 1 月 14 日进行的 .NET 核心 API 审查视频中,这一问题在 API 相关的重要问题中居首位。这段视频录制了针对 .NET 基础类库的十个变更请求的相关讨论。

  [视频] GitHub Issue#316:为正则集合(包括 CaptureCollection、GroupCollection 和 MatchCollection)实现 IList<T>、IReadOnlyList<T>和 IList 接口

  在 .NET 类库中,但凡返回集合类型的属性或方法,多数都会选择使用强类型的集合。这种集合不是诸如 IEnumerable<Foo>或 IList<Foo>等类型,而是强类型的 FooCollection。这种方式对于向后兼容来说更为理想,因为可以放心地在类中加入新的方法,而不必依赖于不安全的类型转换

  其实原因还不只是这一条。在 .NET 1.0 版本中还没有出现泛型,意味着 IList<T>等接口也不存在,因此只能通过创建自定义的类型来保证类型安全。

  当 .NET 发布之后,这些强类型中还有很大一部分没有升级为支持泛型集合接口的类型。因此微软所面对的第一个问题就是,是否应该为正则集合实现泛型接口?

  第二个问题是,是否应该为只读集合实现 IList<T>等接口?自从 .NET 2.0 发布以来,由于只读集合接口的出现,IList<T>应当只用于可变集合类型,这一问题本应迎刃而解。但由于只读集合接口相对较新,有许多 API 依然只支持 IList<T>类型,并仅仅通过文档表示不会对其中的内容进行变更。如果某些方法需要对集合内容进行变更,理论上只需要检查一下 IsReadOnly 属性的值就可以了,但这完全取决于类库开发者和应用程序开发者的自觉性。

  再回到原来的问题上,只读的正则集合是否应该支持 IList<T>接口,以便在让不支持 IReadOnlyList<T>接口的遗留 API 也可以调用呢?还是应当选择不支持 IList<T>接口,以减少被某些需要可变的列表的方法所误用呢?

  另一个对此问题起到影响的因素是,Windows Forms 中的数据绑定是依赖于 IList 接口的,因此如果要在用户界面中使用这些正则类型,就必须添加该接口。

  结论:按照当下的设计指南的做法,为这些类型实现所有接口。从长期的考虑来看,考虑对设计指南做某些调整。

  与之相关的另一个问题是,是否应该让这些类型继承于 ReadOnlyCollection<T>类?虽然这种方式能够免去大量的模板代码,但会造成一些向后兼容的问题:

  • 重载解析会产生变化(这个问题同样会发生在添加新接口的方案中)。
  • 使用反射的结果也会产生变化。

  结论:今后,所有新的只读集合都将继承于 ReadOnlyCollection<T>,而现有的类型则保持不变。

  序列化是另一个问题。由于序列化类库中的一些历史悠久的 bug 的问题,如果为类型加入对 IList 或其它接口的支持,有可能造成原本正常的序列化失败。

  结论:如果造成了序列化的失败,则必须撤消该变更。

  [视频] GitHub Issue#110:为 XLinq 的 doucment 和 element 加载加入 async 实现

  对于这一请求的第一个问题是,应该使用方法重载还是可选参数?对于这个 API 来说,问题主要是针对 cancellation token 参数而言,但同样的问题也多次出现在其它场合中。

  对于可选参数的反对意见在于它们对版本化的支持不理解。使用了可选参数之后,如果为某类型加入了一个接受更多参数的新重载,破坏重载解析的可能性就更大。

  结论:可选参数值得一方式,但需要更多的指导与代码分析,以确保它们适当地处理了版本化问题。

  第二个问题是,是否要加入一个支持 URI 的 LoadAsync 方法。整个团队对于该方法的同步版本颇有微词,因为它为 XLinq 类库引入了额外的依赖。

  结论:如果能够让同步版本的 Load (string uri)方法过期,那么也不需要异步的方法了。否则的话,就需要创建一个对应的异步方法,这样也可以便于将来过渡到 async 实现。

  第三个问题是,是否应该为 Load 方法的所有重载都实现对应的 LoadAsync 方法?假设 cancellation token 参数依然保留的情况下,这种方法就将导致方法的数量从 4 个增加到 8 个。而如果 cancellation token 变成了可选参数,则 LoadAsync 的重载方法的数量将变成 16 个,其中的 12 个只是跳转到另外 4 个主要的重载版本。

  结论:首先考虑使用场合最多的方法签名,今后再考虑加入方法重载或可选参数。

  [视频] GitHub Issue#400:为 ImmutableArray<T>类型加入 Cast<T>和 CastFrom<TDerived>方法

  对于不可变数组来说,它们可能会遇到的转换有三种情景:

  • 静态转换为某个基础类型,这种转换必然会成功。例如将 ImmutableArray<Dog>转换为 ImmutableArray<Animal>
  • 动态转换,这种转换有可能会失败。例如将 ImmutableArray<Animal>转换为 ImmutableArray<Dog>。
  • 有条件地转换为某个继承类型,即大家所熟悉的“as 转换”。

  目前只有最后一种转换方式已经得到了完整的支持。通过 ImmutableArray.Create 方法的某个重载可以支持静态转换,但要找到这个重载并不容易,而且这种方法是否会造成额外的内存分配不是一眼就能够看出来的。

  对此问题的一个建议是,删除那个不直观的 Create 方法。添加 Cast 和 CastFrom 方法,以实现静态和动态转换操作。

  对这个 API 的第一个问题是,是否应该使用 Cast 这个方法名称?主要问题在于,Cast 这个名称与 LINQ 中用于元素延迟转换的方法同名。最理想的方案是将 LINQ 中的方法名称改为 CastElements<T>,但这一点明显是不现实的。

  另一个相关的问题是和 As 方法名有关的。通常来说,.NET 会使用 ToXxx 的方法名表示会造成内存分配的转换,而用 AsXxx 的方法名表现无内存分配的转换。而不可变数组中的 As 方法实际上是与 C# 中的“as”caozuofu.html" target="_blank">操作符具有相同的作用,而不是遵循传统意义上的做法。

  另一个问题是和 Visual Basic 有关的。与 C# 不同,在 VB 中可以通过某个实例变量调用它的静态方法。虽然这种方式让人感觉不爽,但它确实已经成为了 VB 语言中的一部分,因此类似 CastFrom 这样的静态方法就让人搞不清到底是将什么转换为什么。

  结论:方法名称依然有改善余地,除此之外,这个提议还是非常有用的。

  [视频] GitHub Issue:#394:为 ConcurrentDictionary<TKey, TValue> 类型加入 GetOrAdd 和 AddOrUpdate 方法重载,其中包括一个 TArg 参数 factoryArgument

  接下来登场的是一个 pull request 中的内容,即为 ConcurrentDictionary 加入新的方法重载。要理解这几个重载的目的,你首先必须理解闭包是如何工作的。当一个闭包产生时,必须对闭包中引用的变量分配内存。如果在一个数量巨大的循环中使用闭包,就会导致大量的内存占用。

  与之相反的是,如果某个匿名方法中没有捕捉(capture)任何本地变量,那么指向该方法的委托就能够被编译器进行缓存并重用。这就使得对该方法的调用不会产生内存分配。

  这些新的方法重载允许你为 GetOrAdd 和 GetOrUpdate 方法中所使用的工厂方法加入一个额外的值。一般情况下,这个额外的值足以代替闭包的使用,因此可以减少内存的占用。

  这些方法也可以被实现为扩展方法,其性能和普通方法相比基本相同。因此对这个问题的讨论主要在于,该方法带来的性能优势和作为普通方法的便利性,是否能够抵消由此造成的类的体积膨胀的缺点。

  一个更广泛的问题是,这种模式是否应该在整个 .NET 平台中使用。几乎每个使用了委托的方法,都可以通过这一模式移除对闭包的使用。

  结论:如果能够证明新的方法对性能产生了很大的改善,就决定加入这些新方法。

  明天我们还将继续对这次 API 审查会议的分析。

发表评论
用户名: 匿名