c# - 如果我只能定义一个 GetEnumerator，为什么要实现 IEnumerable(T)？

Question

更新:我感谢所有的评论，这些评论基本上包含了一致的反对意见。虽然提出的每一个反对意见都是有效的，但我觉得棺材上的最终钉子是 Ani's astute observation最终，即使是这个想法表面上提供的一个 微小好处——消除样板代码——也被这个想法本身需要其 < em>拥有样板代码。

所以，是的，相信我:这将是一个坏主意。

只是为了在某种程度上挽救我的尊严:我可能会为了争论而夸大它，但我从来没有真正接受过这个想法 - 只是想听听其他人对此有何评论。诚实。

---

在您将这个问题视为荒谬之前，我请您考虑以下几点:

1. IEnumerable<T>继承自* IEnumerable ，这意味着任何实现 IEnumerable<T> 的类型通常必须实现两者 IEnumerable<T>.GetEnumerator 和(明确地)IEnumerable.GetEnumerator .这基本上相当于样板代码。
2. 你可以foreach在具有 GetEnumerator 的任何类型上方法，只要该方法返回具有 MoveNext 的某种类型的对象方法和 Current属性(property)。因此，如果您的类型定义了带有签名 public IEnumerator<T> GetEnumerator() 的一个 方法, 使用 foreach 对其进行枚举是合法的.
3. 显然，有很多代码需要 IEnumerable<T>接口(interface)——例如，基本上所有的 LINQ 扩展方法。幸运的是，从一个你可以的类型开始foreach在 IEnumerable<T> 上使用 C# 通过 yield 提供的自动迭代器生成很简单关键字。

因此，将所有这些放在一起，我有了一个疯狂的想法:如果我只定义自己的界面，如下所示:

public interface IForEachable<T>
{
    IEnumerator<T> GetEnumerator();
}

然后 每当我定义一个我想被枚举的类型时，我都会实现这个接口(interface)而不是IEnumerable<T> ，无需实现两个 GetEnumerator方法(一种显式)。例如:

class NaturalNumbers : IForEachable<int>
{
   public IEnumerator<int> GetEnumerator()
   {
       int i = 1;
       while (i < int.MaxValue)
       {
           yield return (i++);
       }
   }

   // Notice how I don't have to define a method like
   // IEnumerator IEnumerable.GetEnumerator().
}

最后，为了使此类型与确实期望IEnumerable<T>的代码兼容接口(interface)，我可以定义一个扩展方法来从任何IForEachable<T>到IEnumerable<T>像这样:

public static class ForEachableExtensions
{
    public static IEnumerable<T> AsEnumerable<T>(this IForEachable<T> source)
    {
        foreach (T item in source)
        {
            yield return item;
        }
    }
}

在我看来，这样做使我能够设计出在所有方面都可用的类型，作为 IEnumerable<T> 的实现。 , 但没有那个讨厌的显式 IEnumerable.GetEnumerator在每一个中实现。

例如:

var numbers = new NaturalNumbers();

// I can foreach myself...
foreach (int x in numbers)
{
    if (x > 100)
        break;

    if (x % 2 != 0)
        continue;

    Console.WriteLine(x);
}

// Or I can treat this object as an IEnumerable<T> implementation
// if I want to...
var evenNumbers = from x in numbers.AsEnumerable()
                  where x % 2 == 0
                  select x;

foreach (int x in evenNumbers.TakeWhile(i => i <= 100))
{
    Console.WriteLine(x);
}

你们怎么看待这个想法？我是否遗漏了一些为什么这是错误的原因？

我意识到对于一开始没什么大不了的事情来说，这似乎是一个过于复杂的解决方案(我怀疑任何人真的都非常关心必须显式定义 IEnumerable界面);但它只是突然出现在我的脑海中，我没有看到这种方法会带来任何明显的问题。

一般来说，如果我可以一次编写适量的代码，从而省去不得不多次编写少量代码的麻烦，对我来说, 这是值得的。

_{*这是正确的术语吗？我总是犹豫说一个接口(interface)“继承自”另一个接口(interface)，因为这似乎没有正确地捕捉到它们之间的关系。但也许它是正确的。}

Answer 1

你错过了一件大事 -

如果您实现自己的接口(interface)而不是 IEnumerable<T> ，您的类(class)将无法使用期望 IEnumerable<T> 的框架方法- 主要是，您将完全无法使用 LINQ，或使用您的类来构建 List<T> ，或许多其他有用的抽象。

正如您提到的，您可以通过单独的扩展方法来完成此操作 - 但是，这是有代价的。通过使用扩展方法转换为 IEnumerable<T> ，您正在添加另一个抽象级别，以便使用您的类(您将比创建类更频繁地执行 FAR)，并且您降低了性能(您的扩展方法实际上将在内部生成一个新的类实现，这真的没有必要)。最重要的是，你的类(class)的任何其他用户(或你以后)将不得不学习一个没有完成任何事情的新 API - 你通过不使用标准接口(interface)使你的类(class)更难使用，因为它违反了用户的期望。