Linq 的 Enumerable.Count 方法检查 ICollection<>但不检查 IReadOnlyCollection<>

背景：

Linq-To-Objects 具有扩展方法Count()（不采用谓词的重载）。当然，有时当一个方法只需要一个IEnumerable<out T>（做Linq）时，我们真的会给它传递一个"更丰富"的对象，比如ICollection<T>。在这种情况下，实际遍历整个集合（即获取枚举器并"下一步移动"一大堆次数）来确定计数是浪费的，因为有一个属性ICollection<T>.Count用于此目的。而这个"快捷方式"从Linq开始就已经在BCL中使用了。

现在，从.NET 4.5（2012年）开始，还有另一个非常好的界面，即IReadOnlyCollection<out T>。它与ICollection<T>类似，只是它只包括那些返回T的成员。因此，它可以在T（"out T"）中协变，就像IEnumerable<out T>一样，当项目类型可以或多或少地派生时，这真的很好。但是新界面有自己的属性， IReadOnlyCollection<out T>.Count .请参阅SO的其他地方，为什么这些Count属性是不同的（而不仅仅是一个属性）。

问题：

Linq 的方法Enumerable.Count(this source)检查ICollection<T>.Count，但不检查IReadOnlyCollection<out T>.Count。

鉴于在只读集合上使用 Linq 确实很自然且常见，更改 BCL 以检查这两个接口是否是一个好主意？我想这需要一次额外的类型检查。

这会是一个重大变化吗（鉴于他们没有"记住"从引入新界面的 4.5 版本中执行此操作）？

示例代码

运行代码：

    var x = new MyColl();
    if (x.Count() == 1000000000)
    {
    }
    var y = new MyOtherColl();
    if (y.Count() == 1000000000)
    {
    }

其中MyColl是实现IReadOnlyCollection<>但不是ICollection<>的类型，其中MyOtherColl是实现ICollection<>的类型。具体来说，我使用了简单/最小的类：

class MyColl : IReadOnlyCollection<Guid>
{
  public int Count
  {
    get
    {
      Console.WriteLine("MyColl.Count called");
      // Just for testing, implementation irrelevant:
      return 0;
    }
  }
  public IEnumerator<Guid> GetEnumerator()
  {
    Console.WriteLine("MyColl.GetEnumerator called");
    // Just for testing, implementation irrelevant:
    return ((IReadOnlyCollection<Guid>)(new Guid[] { })).GetEnumerator();
  }
  System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
  {
    Console.WriteLine("MyColl.System.Collections.IEnumerable.GetEnumerator called");
    return GetEnumerator();
  }
}
class MyOtherColl : ICollection<Guid>
{
  public int Count
  {
    get
    {
      Console.WriteLine("MyOtherColl.Count called");
      // Just for testing, implementation irrelevant:
      return 0;
    }
  }
  public bool IsReadOnly
  {
    get
    {
      return true;
    }
  }
  public IEnumerator<Guid> GetEnumerator()
  {
    Console.WriteLine("MyOtherColl.GetEnumerator called");
    // Just for testing, implementation irrelevant:
    return ((IReadOnlyCollection<Guid>)(new Guid[] { })).GetEnumerator();
  }
  System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
  {
    Console.WriteLine("MyOtherColl.System.Collections.IEnumerable.GetEnumerator called");
    return GetEnumerator();
  }
  public bool Contains(Guid item) { throw new NotImplementedException(); }
  public void CopyTo(Guid[] array, int arrayIndex) { throw new NotImplementedException(); }
  public bool Remove(Guid item) { throw new NotSupportedException(); }
  public void Add(Guid item) { throw new NotSupportedException(); }
  public void Clear() { throw new NotSupportedException(); }
}

并得到输出：

MyColl.GetEnumerator 调用MyOtherColl.Count 调用

从代码运行中，这表明在第一种情况下未使用"快捷方式"（IReadOnlyCollection<out T> ）。在 4.5 和 4.5.1 中可以看到相同的结果。

在其他地方评论后更新堆栈溢出由用户supercat .

当然，Linq 是在 .NET 3.5 （2008）中引入的，而 IReadOnlyCollection<> 仅在 .NET 4.5 （2012）中引入。但是，在这两者之间，在 .NET 4.0 （2010）中引入了另一个功能，即泛型中的协方差。正如我上面所说，IEnumerable<out T>变成了一个协变接口。但是ICollection<T>在T中保持不变（因为它包含像void Add(T item);这样的成员）。

早在 2010 年（.NET 4）中，这会产生这样的结果：如果 Linq 的 Count 扩展方法用于编译时类型的源IEnumerable<Animal>其中实际运行时类型例如List<Cat>，例如，这肯定是一个IEnumerable<Cat>，但也通过协方差，一个IEnumerable<Animal>，那么不使用"快捷方式"。Count 扩展方法仅检查运行时类型为 ICollection<Animal> ，而它不是（无协方差）。它无法检查ICollection<Cat>（它怎么知道Cat是什么，它的TSource参数等于Animal？

我举个例子：

static void ProcessAnimals(IEnuemrable<Animal> animals)
{
    int count = animals.Count();  // Linq extension Enumerable.Count<Animal>(animals)
    // ...
}

然后：

List<Animal> li1 = GetSome_HUGE_ListOfAnimals();
ProcessAnimals(li1);  // fine, will use shortcut to ICollection<Animal>.Count property
List<Cat> li2 = GetSome_HUGE_ListOfCats();
ProcessAnimals(li2);  // works, but inoptimal, will iterate through entire List<> to find count

我建议的IReadOnlyCollection<out T>检查也会"修复"这个问题，因为这是一个由 List<T> 实现的协变接口。

结论：

此外，在运行时类型的source实现IReadOnlyCollection<>但不ICollection<>的情况下，检查IReadOnlyCollection<TSource>将是有益的，因为基础集合类坚持是只读集合类型，因此不希望实现ICollection<>。
（新）如果应用泛型协方差，即使source的类型既ICollection<>又IReadOnlyCollection<>，检查IReadOnlyCollection<TSource>也是有益的。具体来说，IEnumerable<TSource>可能真的是一个ICollection<SomeSpecializedSourceClass>，其中SomeSpecializedSourceClass可以通过参考转换为TSource来转换。 ICollection<>不是协变的。但是，IReadOnlyCollection<TSource>检查将通过协方差起作用;任何IReadOnlyCollection<SomeSpecializedSourceClass>也是IReadOnlyCollection<TSource>，快捷方式将被利用。
成本是每次调用 Linq 的 Count 方法时额外进行一次运行时类型检查。

在许多情况下

，实现IReadOnlyCollection<T>的类也将实现ICollection<T>。因此，您仍将从 Count 属性快捷方式中受益。

例如，请参阅只读集合。

public class ReadOnlyCollection<T> : IList<T>, 
    ICollection<T>, IList, ICollection, IReadOnlyList<T>, IReadOnlyCollection<T>, 
    IEnumerable<T>, IEnumerable

由于检查其他接口以获得给定只读接口之外的访问权限的不良做法，因此这种方式应该没问题。

在Count()中实现对IReadOnlyInterface<T>的附加类型检查将是对未实现IReadOnlyInterface<T>的对象的每个调用的额外镇流器。

根据 MSDN 文档，ICollection<T> 是唯一获得此特殊处理的类型：

如果源的类型实现 ICollection，则该实现用于获取元素计数。否则，此方法确定计数。

我猜他们不认为为了这种优化而弄乱 LINQ 代码库（及其规范）是不值得的。有许多 CLR 类型具有自己的 Count 属性，但 LINQ 无法解释所有这些类型。

相关内容

最新更新

热门标签：