未来的.NET 之多重继承

 
interface IEnumerable<t>
{
   int Count()
   {
       int count = 0;
       foreach (var x in this)
           count++;
       return count;
   }
}
interface IList<t> ...
{
   int Count { get; }
   override int IEnumerable<t>.Count() => this.Count;
}
</t></t></t>




    

正如从上例中可以看到的，实现 IList<T> 的开发人员无需担心覆写 IEnumerable<T>.Count() 方法，因为它将自动获得 IList<T>.Count 。

大家所关注的一个问题是该提议会使接口膨胀。既然可以在 IEnumerable 中添加 Count 方法，为什么不能添加其他所有的 IEnumerable 扩展方法？

Eirenarch 这样写道：

有人会认真考虑将 Count() 添加到 IEnumerable ，对此我有点吃惊。这不是和 Reset 方法同样的问题吗？并非所有的 IEnumerable 都可重置，或是可安全地做计数，因为其中的一些接口是一次性的。现在看这个问题，我想不起曾在 IEnumerable 上使用过 Count() ，只是在数据库 LINQ 调用中使用过，因为我不想冒险让 Count() 消费可枚举类型，或是变得低效。为什么要鼓励更多的 Count() ？

DavidArno 补充道：

哈哈，很高兴能看到对这一提议的争论。基础类库（BCL，Base Class Library）团队早就将各种集合类搞得混杂不堪。就这一点而言，我怀疑团队中是否有人真正考虑过 Barbara Liskov 的建议，她所提出的替换原则如此完全地被打破了。如果将这一提议中的理念赋予团队，这将允许他们造成更大的破坏。想想就十分可怕！

在一次 BCL 会议上：

“OK，各位，我们想让 IEnumerable<T> 接口支持 cons 功能。大家有何建议？”

“这很简单。默认接口方法就能为我们解决这个问题。只需加入 (T head, IEnumerable<T> tail) Cons() => throw new NotImplementedException() ，这就完事了。IEnumerable 的实现者完全可以在闲暇时添加这一实现。”

“非常好，搞定。谢谢大家，本周会议结束。”

注意，LINQ 是由另一个独立团队负责的。LINQ 的功能并没有计划要切实地迁移到 IEnumerable 中。

这一更改也会打破当前扩展方法所提供的层次。目前 Enumerable.Count 方法位于 System.Core 动态库中，比 mscorlib 动态库要高两层。可能有人认为将 LINQ 的部分或完全地加入 mscorlib 中，会造成该动态库没有必要的膨胀。

另一个批评意见认为这一提议是没有必要的，因为已经存在允许可选地覆写扩展方法的设计模式。

可覆写扩展方法模式

可重新扩展方法依赖于接口检查。理想情况下只需要对一个接口做检查。但是由于一些历史遗留问题，以 Enumerable.Count 为例，需要检查两个接口。代码如下：

 
public static int Count<tsource>(this IEnumerable<tsource> source) {
   var collectionoft = source as ICollection<tsource>;
   if (collectionoft != null) return collectionoft.Count;
   var collection = source as ICollection;
   if (collection != null) return collection.Count;
   int count = 0;
   using (var e = source.GetEnumerator()) {
       while (e.MoveNext()) count++;
   }
   return count;
}
</tsource></tsource></tsource>

 
class Countable : IEnumerable<int>
{
   public IEnumerator<int> GetEnumerator() {…}
}
</int></int>

 
var x = new Countable();
var y = x.Count();

 
interface INotifyPropertyChanged
{
   event PropertyChangedEventHandler PropertyChanged;
   protected void OnPropertyChanged(PropertyChangedEventArgs args) => PropertyChanged?.Invoke(args);
   protected void OnPropertyChanged([CallerMemberName] string propertyName) => OnPropertyChanged(new PropertyChangedEventArgs(propertyName));
   protected void SetProperty<t>(ref T storage, T value, PropertyChangedEventArgs args)
   {
       if (!EqualityComparer<t>.Default.Equals(storage, value))
       {
           storage = value;
           OnPropertyChanged(args);
       }
   }
   protected void SetProperty<t>(ref T storage, T value, [CallerMemberName] string propertyName) => SetProperty(ref storage, value, new PropertyChangedEventArgs(propertyName));
}
</t></t></t>