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

本文关键字:不检查 IReadOnlyColl ICollection 检查 Enumerable Count 方法 Linq | 更新日期: 2023-09-27 17:57:17

背景:

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> 实现的协变接口。

结论:

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

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

在许多情况下

,实现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 无法解释所有这些类型。