C#学习笔记（三）—–C#高级特性：实现迭代器的捷径

最新推荐文章于 2024-02-26 09:16:57 发布

w343516704

最新推荐文章于 2024-02-26 09:16:57 发布

阅读量519

点赞数

分类专栏： c#语言基础文章标签：迭代器 c# 迭代对象通信

本文链接：https://blog.csdn.net/w343516704/article/details/72630114

版权

c#语言基础专栏收录该内容

37 篇文章 7 订阅

订阅专栏

实现迭代器的捷径

本章摘自《C# in depth》，内容包括：
在C#1中实现迭代器
C#中的迭代器块
迭代器使用示例
使用迭代器作为协同程序

迭代器模式 是行为模式的一种范例，行为模式是一种简化对象之间通信的设计模式。这是一种非常易于理解和使用的模式。实际上，它允许你访问一个数据项序列中的所有元素，而无须关心序列是什么类型—— 数组、列表、链表或任何其他类型。它能非常有效地构建出一个数据管道，经过一系列不同的转换或过滤后再从管道的另一端出来。实际上，这也是 LINQ 的核心模式之一。

在. NET 中，迭代器模式是通过 IEnumerator 和 IEnumerable 接口及它们的泛型等价物来封装的（命名上有些不恰当—— 涉及模式时通常称为迭代而非枚举，就是为了避免和枚举这个词的其他意思相混淆，本章将使用迭代器和可迭代的）。如果某个类型实现了 IEnumerable 接口，就意味着它可以被迭代访问。调用 GetEnumerator 方法将返回 IEnumerator 的实现，这就是迭代器本身。可以将迭代器想象成数据库的游标，即序列中的某个位置。迭代器只能在序列中向前移动，而且对于同一个序列可能同时存在多个迭代器操作。

作为一门语言， C# 1 利用 foreach 语句实现了访问迭代器的内置支持。这让我们遍历集合时无比容易（比直接使用 for 循环要方便得多）并且看起来非常直观。 foreach 语句被编译后会调用 GetEnnumerator和 MoveNext 方法以及 Current 属性，假如 IDisposable 也实现了，程序最后还会自动销毁迭代器对象。这是一个虽不起眼但却很有用的语法糖。

然而，在 C# 1 中，实现迭代器是比较困难的。 C# 2 所提供的语法糖可以大大简化这个任务，所以有时候更应该去实现迭代器模式。否则会导致更多的工作量。

本章将研究实现迭代器所需的代码，以及 C# 2 所给予的支持。在详细介绍了语法之后，我们将研究一些现实世界中的示例，包括微软并发函数库（ concurrency library）中对迭代器语法振奋人心的使用（虽然有点异乎寻常）。我会在描述完全部细节之后再提供示例，因为要学的内容并不多，而且在理解了代码的功能之后再去看示例，要清晰得多。

C# 1：手写迭代器的痛苦

为了能顺利过渡到 C# 2 的特性上，首先实现一个相对简单的迭代器，但它仍可以提供真实有用的值。假设我们有一个基于循环缓冲区的新的集合类型。我们将实现 IEnumerable 接口，以便新类的用户能轻松地迭代集合中的所有值。在这里，我们不关心这个集合中的内容是什么，仅仅关注迭代器的实现。这个集合将把值存储在一个数组中（就是 object[ ]，这里不使用泛型），并且集合有一个有趣的特性，就是能设置它的逻辑“ 起点”。所以如果数组有 5 个元素，并且你把起点设置为 2，这样的话我们就看到元素 2、 3、 4、 0 和 1 依次返回。这里不会展示完整的循环缓冲代码，你可以在可下载的代码中找到它们。
为了方便演示这个类，我们将在构造函数中设置值和起点。所以，编写 代码清单 1，来对集合进行迭代。

//【代码清单1】
 static void Main()
        {
            object[] values = { "a", "b", "c", "d", "e" };
            IterationSample collection = new IterationSample(values, 3);
            foreach (object x in collection)
            {
                Console.WriteLine(x);
            }
        }

运行代码清单1应该（最终）会产生输出结果 d、 e、 a、 b 和 c，因为之前设置的起点为 3。现在知道我们要完成的功能了，下面来看一下在 代码清单2中这个类的框架。

//【代码清单2】
 class IterationSample : IEnumerable
    {
        object[] values;
        int startingPoint;

        public IterationSample(object[] values, int startingPoint)
        {
            this.values = values;
            this.startingPoint = startingPoint;
        }

        public IEnumerator GetEnumerator()
        {
           throw new NotImplementedException();
        }
    }

正如你看到的，现在还未实现 GetEnumerator 方法，不过其余的代码已经可以运行了。那么，要如何实现 GetEnumerator 方法呢？首先要知道，我们需要在某个地方存储某个状态。迭代器模式的一个重要方面就是，不用一次返回所有数据—— 调用代码一次只需获取一个元素。这意味着我们需要确定访问到了数组中的哪个位置。在了解 C# 2 编译器为我们所做的事情时，迭代器的这种状态特质十分重要，因此要密切关注本例中的状态。那么，这个状态值要保存在哪里呢？假设我们尝试把它放在 IterationSample 类自身里面，让它既实现 IEnumerator 接口又实现 IEnumerable 接口。乍一看，这似乎是个好主意—— 毕竟，我们是将数据保存在正确的位置，其中也包括了起点。 GetEnumerator 方法可以仅返回 this。然而，使用这种方式存在一个大问题—— 如果 GetEnumerator 方法被调用了多次，那么就会返回多个独立的迭代器。例如，我们能使用两个嵌套的 foreach 语句，以便得到所有可能的成对值。这就意味着，两个迭代器需要彼此独立，每次调用 GetEnumerator 方法时都需要创建一个新对象。我们仍可以直接在 IterationSample 内部实现功能，不过只用一个类的话，分工就不明确—— 那样会让代码非常混乱。因此，可以创建另外一个类来实现这个迭代器。我们将使用“ C# 嵌套类型可以访问它外层类型的私有成员” 这一特点，就是说，我们仅需要存储一个指向“ 父级” IterationSample 类型的引用和关于所访问到的位置位置的状态，如 代码清单 3所示。

//【代码清单3】：嵌套类实现集合迭代器
  class IterationSampleIterator : IEnumerator
        {
            IterationSample parent; //❶ 正在 迭代 的 集合 
            int position; //❷ 指出 遍历 到 的 位置 
            internal IterationSampleIterator(IterationSample parent)
            {
                this.parent = parent; 
                position = -1; //❸ 在 第一个 元素 之前 开始 
            }
            public bool MoveNext()
            {
                if (position != parent.values.Length) //❹ 如果 仍 要 遍历， 那么 增加 position 的 值
                {
                    position++;
                }
                return position < parent.values.Length;
            }
            public object Current
            {
                get
                {
                    if (position == -1 ||position == parent.values.Length) //❺ 防止 访问 第一个 元素 之前 和 最后 一个 元素 之后 

                    {
                        throw new InvalidOperationException();
                    }
                    int index = position + parent.startingPoint; /*❻ 实现 封闭*/
                    index = index % parent.values.Length;
                    return parent.values[index];
                }
            }
            public void Reset()
            {
                position = -1; //❼ 返回 第一个 元素 之前 
            }
        }

这么简单的一个任务竟然使用了这么多代码！我们要记住进行迭代的原始值的集合 ❶，并用简单的从零开始的数组跟踪我们所在的位置 ❷。为了返回元素，要根据开始点对索引进行偏移 ❻。为了和接口一致，要让迭代器逻辑上从第一个元素的位置之前开始 ❸，所以在第一次使用 Current 属性之前，调用代码必须调用 MoveNext 方法。 ❹ 中的条件增量可以保证 ❺ 中的条件判断简单准确，即使在程序第一次报告无可用数据后又调用 MoveNext 也没有问题。为了重置迭代器，我们将我们的逻辑位置设置回“ 第一个元素之前” ❼。

这里涉及的大部分逻辑都非常简单，当然还是有大量的地方会出现“ 边界条件逻辑错误”（ off- by- one error）。实际上，我的第一个实现就是因为这个原因没有通过单元测试。不过，幸好它现在可以正常运行了，现在只需在 IterationSample 中实现 IEnumerable 接口来完成这个例子：

//【代码清单4】
public IEnumerator GetEnumerator()
{
  return new IterationSampleIterator( this);
}

要谨记这只是一个相对简单的例子—— 没有太多的状态需要跟踪，也没有尝试检查集合是否在两次迭代之中被改变。实现一个简单的迭代器都需要花费这么大的精力，所以很少有人能在 C# 1 中实现这个模式也不足为奇。开发人员通常喜欢用 foreach 在由框架提供的集合上执行迭代，或使用更直接（和集合特定）的方式来访问他们自己构建的集合。因此，在 C# 1 中用了 40 行代码来实现迭代器。下面来看一下在 C# 2 中情况能否好转。

C# 2：利用 yield 语句简化迭代器

　迭代器块和 yield return 简介：如果 C# 2 不具备缩减实现迭代器所编写的代码量这个强大的特性，那么本章就没有存在的必要了。在其他主题中，代码量只会减少一点点，或者仅仅使编写出的代码更优雅。然而在这里，所需的代码量大大地减少了。代码清单5 展示了在 C# 2 中 GetEnumerator 方法的完整实现。

//【代码清单5】
 public IEnumerator GetEnumerator()
        {
            for (int index = 0; index < values.Length; index++)
            {
                yield return values[(index + startingPoint) % values.Length];
            }
        }

现在，整个IterationSample类是这样的：

//【代码清单6】
 public class IterationSample : IEnumerable
    {
        object[] values;
        int startingPoint;

        public IterationSample(object[] values, int startingPoint)
        {
            this.values = values; this.startingPoint = startingPoint;
        }

        public IEnumerator GetEnumerator()
        {
            for (int index = 0; index < values.Length; index++)
            {
                yield return values[(index + startingPoint) % values.Length];
            }
        }     
    }

4 行代码就搞定了，其中还有两行大括号。明确地讲，它们完全替换掉了整个 IterationSampleIterator 类。至少在源代码中是这样的…… 稍后，我们将看到编译器在后台都做了哪些工作，以及这个实现的奇特之处。不过此时还是先看一下这里用到的源代码。

在你看到 yield return 之前，这个方法看上去一直都非常正常。这句代码就是告诉 C# 编译器，这个方法不是一个普通的方法，而是实现一个迭代器块的方法。这个方法被声明为返回一个 IEnumerator 接口，所以就只能使用迭代器块来实现返回类型为 IEnumerable、 IEnumerator 或泛型等价物的方法（或者属性也可，我们后面会看到。但是不能在匿名方法中使用迭代器代码块。）如果方法声明的返回类型是非泛型接口，那么迭代器块的生成类型（ yield type）是 object，否则就是泛型接口的类型参数。例如，如果方法声明为返回 IEnumerable< string>，那么就会得到 string 类型的生成类型。

在迭代器块中不允许包含普通的 return 语句—— 只能是 yield return。在代码块中，所有 yield return 语句都必须返回和代码块的生成类型兼容的值。在之前的例子中，不能在一个声明返回 IEnumerable< string> 的方法中编写 yield return 1; 这样的代码。

说明： 对 yield return 的限制　对 yield 语句有一些额外的限制。如果存在任何 catch 代码块，则不能在 try 代码块中使用 yield return，并且在 finally 代码块中也不能使用 yield return 或 yield break（这个语句马上就要讲到）。这并非意味着不能在迭代器内部使用 try/ catch 或 try/ finally 代码块，只是说使用它们时有一些限制而已。如果想了解为什么会存在这样的限制，可以查看 Eric Lippert 的一个博文系列，其中介绍了这种限制以及迭代器方面的其他设计决策，网址为 http:// mng. bz/ EJ97。

编写迭代器块时，需要记住 重要的一点：尽管你编写了一个似乎是顺序执行的方法，但实际上是请求编译器为你创建了一个状态机。编译器这样做的原因，和我们在 C# 1 的迭代器实现中塞入那么多代码的原因完全一样—— 调用者每次只想获取一个元素，所以在返回上一个值时需要跟踪当前的工作状态。当编译器看到迭代器块时，会为状态机创建一个嵌套类型，来正确记录块中的位置以及局部变量（包括参数）的值。所创建的类类似于我们之前用普通方法实现的类，用实例变量来保存所有必要的状态。下面来看一下，要实现迭代器，这个状态机要做哪些事情：
①它必须具有某个初始状态；
②每次调用 MoveNext 时，在提供下一个值之前（换句话说，就是执行到 yield return 语句之前），它需要执行 GetEnumerator 方法中的代码；
③ 使用 Current 属性时，它必须返回我们生成的上一个值；
④它必须知道何时完成生成值的操作，以便 MoveNext 返回 false。
要实现上述内容的第二点需要一定的技巧，因为它总是要从之前达到的位置“ 重新开始” 执行代码。跟踪局部变量（当变量处于方法中时）不算太难—— 它们在状态机中由实例变量来表示。而重新启动（指继续执行 yield return 之后的代码。）的动作更需技巧，不过好在你不用自己编写 C# 编译器，所以不用关心它是如何实现的，只要明白从黑盒出来的结果能正确工作就行。在迭代器块中，你可以编写普通代码，编译器负责确保执行流程和在其他方法中一样正确。不同的是， yield return 语句只表示“ 暂时地” 退出方法—— 事实上，你可把它当作暂停。
接下来，我们用更加形象的方式深入研究执行流程。

观察迭代器的工作流程

使用序列图的方式有助我们充分了解迭代器是如何执行的。我们不用手工绘制这个图，而是用程序把流程打印出来（ 代码清单7）。这个迭代器本身仅仅提供了一个数字序列（ 0, 1, 2,- 1）。有意义的部分不是这些数字，而是代码的流程。

//【代码清单7】
static readonly string Padding = new string(' ', 30);
static IEnumerable<int> CreateEnumerable()
{
Console.WriteLine("{0}Start of CreateEnumerable()", Padding);
for (int i=0; i < 3; i++)
{
Console.WriteLine("{0}About to yield {1}", Padding, i);
yield return i;
Console.WriteLine("{0}After yield", Padding);
}
Console.WriteLine("{0}Yielding final value", Padding);
yield return -1;
Console.WriteLine("{0}End of CreateEnumerable()", Padding);
}
...
IEnumerable<int> iterable = CreateEnumerable();
IEnumerator<int> iterator = iterable.GetEnumerator();
Console.WriteLine("Starting to iterate");
while (true)
{
Console.WriteLine("Calling MoveNext()...");
bool result = iterator.MoveNext();
Console.WriteLine("... MoveNext result={0}", result);
if (!result)
{
break;
}
Console.WriteLine("Fetching Current...");
Console.WriteLine("... Current result={0}", iterator.Current);
}

代码清单 7的代码确实不够优雅，尤其进行迭代的代码更是如此。在通常的写法中，我们一般使用 foreach 循环语句，不过为了完全地展现运行过程中何时发生何事，须把迭代器分割为一些很小的片段。这段代码的作用同 foreach 大致相同，然而 foreach 还会在最后调用 Dispose 方法，随后我们会看到，这对于迭代器块是很重要的。可以看到，虽然这次我们返回的是 IEnumerable< int> 而非 IEnumerator< int>，但迭代器方法里的语法没有任何区别。通常为了实现 IEnumerable< T>，我们只会返回 IEnumerator< T>。如果你只想在方法中生成一个序列，可以返回 IEnumerable< T>。
这里写图片描述

这个结果中有几个重要的事情需要牢记：
①在第一次调用 MoveNext 之前， CreateEnumerable 中的代码不会被调用；
② 所有工作在调用 MoveNext 时就完成了，获取 Current 的值不会执行任何代码； ③在 yield return 的位置，代码就停止执行，在下一次调用 MoveNext 时又继续执行；
④在一个方法中的不同地方可以编写多个 yield return 语句；
⑤ 代码不会在最后的 yield return 处结束，而是通过返回 false 的 MoveNext 调用来结束方法的执行。
第一点尤为重要，因为它意味着如果在方法调用时需要立即执行代码，就不能使用迭代器块，如参数验证。如果你将普通检查放入用迭代器块实现的方法中，将不能很好地工作。你肯定会在某些时候违反这些约束—— 这是十分常见的错误，而且如果你不知道迭代器块的原理，也很难理解为什么会这样。下面的内容中将解决这个问题。有两件事情我们之前尚未接触到—— 终止迭代过程的其他方式，以及 finally 代码块如何在这种有点古怪的执行形式中工作。现在来看一下。

进一步了解迭代器执行流程

在常规的方法中， return 语句具有两个作用：第一，给调用者提供返回值；第二，终止方法的执行，在退出时执行合适的 finally 代码块。我们看到 yield return 语句临时退出了方法，直到再次调用 MoveNext 后又继续执行，我们根本没有检查 finally 代码块的行为。如何才能真正地停止方法？所有这些 finally 代码块发生了什么？我们从一个非常简单的构造（ yield break 语句）开始。
①使用 yield break 结束迭代器的执行人们总希望找到某种方式来让方法具有单一的出口点，很多人也很努力地实现这个目标（作者：我个人认为，为实现这个目标你所使用的方法可能会使代码很难阅读，不如设置多个出口点，尤其在需要估计任何可能发生的异常并使用 try/ finally 进行资源清理时。不过，关键是做到这一点不难）。同样的技术也适用于迭代器块。不过，如果你希望“ 提早退出”，那么 yield break 语句正是你所需要的。它实际上终止了迭代器的运行，让当前对 MoveNext 的调用返回 false。 代码清单8演示了在计数到 100 次的过程中，假如运行超过时限就提前停止的情况。它也演示了在迭代器块中使用方法参数（记住，迭代器块不能实现具有 ref 或 out 参数的方法。）的方式，并证实这与方法的名称是无关的。

//【代码清单8】
static IEnumerable<int> CountWithTimeLimit(DateTime limit)
{
for (int i = 1; i <= 100; i++)
{
if (DateTime.Now >= limit)
{
yield break;//如果时间到了就停止
}
yield return i;
}
}
...
DateTime stop = DateTime.Now.AddSeconds(2);
foreach (int i in CountWithTimeLimit(stop))
{
Console.WriteLine("Received {0}", i);
Thread.Sleep(300);
}

正常情况下，运行代码清单 6- 6 时将看到大约 7 行的输出结果。如我们所预计的那样， foreach 循环能够正常地结束，迭代器遍历完了需要遍历的元素。 yield break 语句的行为非常类似于普通方法中的 return 语句。到目前为止，一切都还相对简单。执行流程的最后一个要研究的地方是： finally 代码块如何执行及何时执行。
②finally 代码块的执行在要离开相关作用域时，我们习惯执行 finally 代码块。迭代器块行为方式和普通方法不太一样，尽管我们也看到， yield return 语句暂时停止了方法，但并没有退出该方法。按照这样的逻辑，在这里我们不要期望任何 finally 代码块能够正确执行—— 实际也确实如此。不过，在遇到 yield break 语句时，适当的 finally 代码块还是能够执行的，正如在从普通方法中返回时你所期望的那样（在未执行 yield return 或 yield break 语句之前而离开相关作用域时，它们也会执行。在这里，我只关注这两种 yield 语句的行为，因为它们的执行流程是不同的。）finally 在迭代器块中常用于释放资源，通常与 using 语句配合使用。后面还会介绍一个真实的例子，但现在我们先来看看 finally 块何时以及如何执行。 代码清单 9展示了一个示例—— 它在 代码清单8的基础上添加了 finally 代码块。改变的地方使用粗体显示。

//【代码清单9】
static IEnumerable<int> CountWithTimeLimit(DateTime limit)
{
try
{
for (int i = 1; i <= 100; i++)
{
if (DateTime.Now >= limit)
{
yield break;
}
yield return i;
}
}
finally
{
Console.WriteLine("Stopping!");//不管循环是否结束都执行
}
}
...
DateTime stop = DateTime.Now.AddSeconds(2);
foreach (int i in CountWithTimeLimit(stop))
{
Console.WriteLine("Received {0}", i);
Thread.Sleep(300);
}

在 代码清单 9 中，如果迭代器块计数到了 100 或者由于时限而停止， finally 代码块都会执行。（如果代码抛出一个异常，它也会执行。）不过，在其他情况下我们可能想避免调用 finally 块中的代码，我们来走个捷径。我看到当调用 MoveNext 时只有迭代器块中的这段代码被执行。那么如果从不调用 MoveNext 会发生什么呢？或者如果我们只调用几次，而后就停止呢？看看把 代码清单9 的“ 调用” 部分改为下面这样会怎么样：

//【代码清单10】
DateTime stop = DateTime.Now.AddSeconds(2);
foreach (int i in CountWithTimeLimit(stop))
{
Console.WriteLine ("Received {0}", i);
if (i > 3)
{
Console.WriteLine("Returning");
return;
}
Thread.Sleep(300);
}

在这里，我们不是提前停止执行迭代器代码，而是提前停止使用迭代器。输出结果也许令人感到意外：
Received 1
Received 2
Received 3
Received 4
Returning
Stopping!
此处，在 foreach 循环中的 return 语句执行后，迭代器的 finally 代码也被执行了。这通常是不应发生的，除非 finally 代码块被调用了—— 在这种情况下，被调用了两次！虽然我们知道在迭代器方法中存在着 finally 代码块，但问题是什么原因引起它执行的呢。我之前也提到过—— foreach 会在它自己的 finally 代码块中调用 IEnumerator 所提供的 Dispose 方法（就像 using 语句）。当迭代器完成迭代之前，你如果调用由迭代器代码块创建的迭代器上的 Dispose，那么状态机就会执行在代码当前“ 暂停” 位置范围内的任何 finally 代码块。这个解释复杂且有点详细，但结果却很容易描述：只要调用者使用了 foreach 循环，迭代器块中的 finally 将按照你期望的方式工作。只需通过手动使用迭代器，我们就能非常容易地证明对 Dispose 的调用会触发 finally 代码块的执行：

DateTime stop = DateTime.Now.AddSeconds(2);
IEnumerable<int> iterable = CountWithTimeLimit(stop);
IEnumerator<int> iterator = iterable.GetEnumerator();
iterator.MoveNext();
Console.WriteLine("Received {0}", iterator.Current);
iterator.MoveNext();
Console.WriteLine("Received {0}", iterator.Current);

这次，“ stopping” 行不会打印出来。而如果增加一个对 Dispose 的显式调用，就会在输出中看到这一行。在迭代器完成之前终止它的执行是相当少见的，并且不用 foreach 语句而手动使用迭代器也是不多见的，不过如果你这样做，记得把迭代器包含在 using 语句中使用。我们现在已经研究了迭代器块的大部分行为了，不过在结束本小节之前，还是值得研究一下在目前微软实现中的一些奇特之处。

具体实现中的奇特之处

如果你使用微软 C# 2 编译器编译迭代器块，并使用 ildasm 或 Reflector 来查看生成的 IL，你将看到编译器在幕后为我们生成的嵌套类型。对于我的例子，当编译代码清单 6- 4 的时候，它调用了 IterationSample.< GetEnumerator> d__ 0（顺便说下，在这里的尖括号不是代表泛型类型参数。）我们无法在这里详细地讲解所生成的代码，但应该在 Reflector 中看看具体发生的情况，建议参考语言规范，在语言规范的 10. 14 节中定义了类型可具有的不同状态，并且其中的描述也有助于理解生成的代码。 MoveNext 通常包含一个很大的 switch 语句，将执行大部分工作。幸好，作为开发人员我们不需要太关心编译器是如何解决这些问题的。不过，关于实现中的以下一些奇特之处还是值得了解的：在第一次调用 MoveNext 之前， Current 属性总是返回迭代器产生类型的默认值；在 MoveNext 返回 false 之后， Current 属性总是返回最后的生成值； Reset 总是抛出异常，而不像我们手动实现的重置过程那样，为了遵循语言规范，这是必要的行为；嵌套类总是实现 IEnumerator 的泛型形式和非泛型形式（提供给泛型和非泛型的 IEnumerable 所用）。不实现 Reset 是完全合理的—— 编译器无法合理地解决在重置迭代器时需要完成的一些事情，甚至不能判断解决方法是否可行。可以认为， Reset 在 IEnumerator 接口中一开始就不存在，而且我也完全想不起我最后一次调用它是什么时候了。很多集合都不支持 Reset，通常，调用者不能依赖它。实现额外的接口也不会对其产生影响。有意思的是，如果你的方法返回 IEnumerable，那么你最终得到的是一个实现了 5 个接口（包括 IDisposable）的类。语言规范解释的很清楚，不过作为开发人员你不需要关心这些。事实上很少有某个类会同时实现 IEnumerable 和 IEnumerator—— 编译器做了大量的工作，来确保不论你如何处理都正确，通常还会在迭代某个集合时，在创建集合的同一线程上创建一个内嵌类型的实例。 Current 的行为有点奇怪—— 尤其在完成迭代后依然保持着最后的值，会阻止其被垃圾回收。这个问题也许在未来的 C# 编译器中会被修正，不过这不太可能，因为它会破坏已有的代码（和. NET 3. 5 及. NET 4 一起发布的微软 C# 编译器还是如此）。严格来说，从 C# 2 语言规范的角度来看，这样做也是对的—— Current 属性的行为未明确定义。如果它按照框架文档的建议来实现这个属性，在适当的时候抛出异常可能更好些。因此，使用自动生成的代码还是存在一些缺点，不过对于明智的调用者，不会有太大问题，让我们正确对待它，毕竟我们节省了大量需要手动实现的代码。换句话说，迭代器应该比在 C# 1 中使用得更为广泛。下一节提供了一些示例代码，以便检查你对迭代器块的理解，并了解它们在实际的开发中多么有用（而不是仅仅停留在理论上）。

真实的迭代器示例

你是否曾经写过一些其本身非常简单却能让你的项目更加整齐而有条理的代码？这种事对于我来说是经常发生的，这让我常常得意忘形，以至于同事们都用很奇怪的眼神看我。这种稍显幼稚的快乐，在使用一些新语言特性的时候更加强烈，这不仅仅说明我获得了“ 玩新玩具” 的快感，而是这些新特性显然很好。即使现在我已经使用了多年的迭代器，仍然会遇到用迭代器块呈现解决方案的情况，并且结果代码简短、整洁和易于理解。我将与你分享三个这样的例子。

①迭代时刻表中的日期

for (DateTime day = timetable.StartDate;
day <= timetable.EndDate;
day = day.AddDays(1))

我处理过太多这样的代码了，一直讨厌这样的循环，不过当我以伪代码的方式向其他开发人员大声念出这些代码的时候，我才意识到我缺乏一定的交流技巧。我会说“ 对于时刻表中的每一天”。回想起来其实很明显，我实际上是需要一个 foreach 循环。（这些可能从一开始对你来说就是显而易见的，如果你恰好属于这种情况，那么请原谅我说了这么多。幸好，我看不到你此时的表情。）当重写为下述代码的时候，这个循环就显得好多了：

foreach (DateTime day in timetable. DateRange)

在 C# 1 中，我也许只会把它当做一个美梦，而不会自寻烦恼去实现它：我们之前看到要手动实现一个迭代器有多麻烦，而最后的结果只是使几个 for 循环变得整洁了一些。然而，在 C# 2 中，它就非常简单了。在一个表示时刻表的类中，我仅仅添加了一个属性：

public IEnumerable<DateTime> DateRange
{
get
{
for (DateTime day = StartDate;
day <= EndDate;
day = day.AddDays(1))
{
yield return day;
}
}
}

原始的循环代码被移动到了时刻表类中，这样很好—— 这些代码被封装到一个对“ 天” 进行循环的属性中，并一次生成 1 个，这样做比在业务代码中处理这些“ 天” 要好很多。如果我想做得更复杂些（例如，跳过周末和公休假），还可以做到在一个地方封装代码，在任何地方使用它。这个小小的更改，在很大程度上改善了代码库的可读性。因此，这时我停止了对商业代码的重构。我确实也考虑过引入一个 Range< T> 类型，来表示一个通用的范围，但由于只在这一种情况下需要它，所以为此而付出更多的努力似乎没有什么意义。事实证明，这是一个明智之举。在本书第 1 版中，我创建了这样一个类型，但它有一些很难在书面上描述
的缺点。我在我的工具库中重新设计了这个类型，但仍然还有一些忧虑。这种类型通常听上去要比实际情况简单，然而不久你就需要频繁地处理一些个别情况。我所遇到的这些困难的细节超出了本书的范围，它们大多是对于通用的设计而言的，不是 C# 本身，但它们却十分有趣，因此我在本书网站上撰写了一篇文章来描述这些情况（参见 http:// mng. bz/ GAmS）。下面这个例子也是我喜欢的，它能充分说明我衷情迭代器块的原因。

②迭代文件中的行
想一想你曾多少次逐行阅读文本文件吧，这实在是一个再平常不过的任务了。而在. NET 4 中，框架最终提供了一种方法，使得这项任务通过 reader. ReadLines 来实现要简单得多。但如果你曾使用过该框架的早期版本，你也可以轻松创建自己的代码，如同我将在接下来的内容中介绍的那样。我都不知道自己曾经写过多少次这样的代码：

using (TextReader reader = File.OpenText(filename))
{
string line;
while ((line = reader.ReadLine()) != null)
{
// Do something with line
}
}

这里共有四个不同的概念：
如何获取 TextReader；
管理 TextReader 的生命周期；
迭代 TextReader. ReadLine 返回的行；
对这些行进行处理。
只有第一条和最后一条是因势而变的—— 生命周期管理和迭代机制都是样板代码。（至少 C# 的生命周期管理非常简单，感谢 using 语句！）我们有两种方法可以进行改进。我们可以使用委托—— 编写一个工具方法，将阅读器和委托作为参数，为文件中的每一行调用该委托，最后关闭阅读器。这经常作为闭包和委托的示例，不过我还发现了一个更加优雅的适合于 LINQ 的方法。我们不将逻辑作为委托传入方法，而是使用迭代器一次返回文件中的一行，因此可以使用普通的 foreach 循环。你可以编写一个实现了 IEnumerable< string> 的完整类型来达到这一点（我的 MiscUtil 库中的 LineReader 类就是这种用途），不过其他类中的一个单独的方法也是可以的。它非常简单，如 代码清单 11所示。

static IEnumerable<string> ReadLines(string filename)
{
using (TextReader reader = File.OpenText(filename))
{
string line;
while ((line = reader.ReadLine()) != null)
{
yield return line;
}
}
}
...
foreach (string line in ReadLines("test.txt"))
{
Console.WriteLine(line);
}

在对集合进行迭代时，我们将行产生给调用者，除此之外，方法体与之前几乎完全相同。与之前一样，我们打开文件，一次读取一行，然后在结束时关闭阅读器。尽管这里“ 结束时” 这个概念要比在普通方法中使用 using 语句有趣得多，后者的流控制更为明显。因此在 foreach 循环中释放迭代器非常重要，它可以确保阅读器被清理干净。迭代器方法中的 using 语句扮演了 try/ finally 块的角色。在到达文件末尾或在中途调用 IEnumerater< string> 的 Dispose 方法时，将进入 finally 块。调用代码很可能滥用 ReadLines (…). GetEnumerator() 返回的 IEnumerator< string>，导致资源泄露，但这通常是 IDisposable 的情况—— 如果你没有调用 Dispose，则可能导致泄露。不过这很少发生，因为 foreach 进行了正确的处理。要注意这种潜在的滥用，如果你依赖迭代器中的 try/ finally 块来授予某些权限，然后又将其移除，那么这就是一个安全漏洞。这个方法封装了我之前列出的四个概念中的前三个，但却有一些限制。将生命周期管理和迭代部分结合起来是可以的，但如果我们想从网络流中读取文本或使用 UTF- 8 以外的编码格式呢？我们需要将第一部分交还给调用者来控制。最显而易见的方式是修改方法签名，使其接受一个 TextReader，如下所示：

static IEnumerable< string> ReadLines( TextReader reader)

但这是一个糟糕的方案。我们希望获取阅读器的所有权，这样可以方便地为调用者进行清理。但这样一来就意味着，只要用户使用了该方法，我们就不得不进行清理。问题是，如果在第一次调用 MoveNext() 之前发生了异常，我们就没有机会进行清理了，所有的代码都不会运行。 IEnumerable< string> 本身不是可释放的，但它已经将这一部分的状态保存为“ 需要释放”。如果 GetEnumerator() 被调用两次，还会产生另一个问题：本应生成两个独立的迭代器，但它们却使用相同的阅读器。我们通过将返回类型改为 IEnumerator< string> 可以在一定程度上缓解这个问题，但这样其结果就无法用于 foreach 循环了，并且如果我们没有到达第一次调用 MoveNext() 就出现了错误，则仍然无法运行任何清理代码。幸运的是，有一个办法可以解决这个问题。因为我们的代码不是立即执行的，因此并不立即就需要阅读器。我们需要的是在需要阅读器的时候获取它的方式。我们可以使用接口来表示“ 可以在需要的时候提供一个 TextReader”，不过含有单一方法的接口总是会让你想到委托。我们这里要小小地做一下弊，使用. NET 3. 5 中的一个委托。它含有不同参数类型数量的重载，但我们只需要一个：

public delegate TResult Func< TResult>()

如你所见，该委托没有参数，返回类型与类型参数的类型相同。这是典型的提供器和工厂方法的签名。在本例中，我们想要获取一个 TextReader，因此使用 Func< TextReader>。对方法的更改非常简单：

static IEnumerable<string> ReadLines(Func<TextReader> provider)
{
using (TextReader reader = provider())
{
string line;
while ((line = reader.ReadLine()) != null)
{
yield return line;
}
}
}

现在，我们只有在需要的时候才去获取资源，并且那时我们处于 IDisposable 的上下文中，可以在适当的时候释放资源。此外，如果对其返回值多次调用 GetEnumerator()，每次都将创建独立的 TextReader。我们可以简单地使用匿名方法来添加打开文件的重载，也可以指定文件的编码：

static IEnumerable<string> ReadLines(string filename)
{
return ReadLines(filename, Encoding.UTF8);
}
static IEnumerable<string> ReadLines(string filename, Encoding encoding)
{
return ReadLines(delegate {
return File.OpenText(filename, encoding);
});
}

这个简单的示例使用了泛型、匿名方法（捕获了所在方法的参数）和迭代器块。“ 三缺一” 的是可空类型，否则就汇集了 C# 2 主要特性的“ 大四喜”。我曾多次使用过这些代码，它比我们开始时介绍的笨重代码要整洁得多。如同前文提到的那样，如果使用的是. NET 的较新版本，你就可以通过 File. ReadLines 来做到。但这仍然可作为一个例子，说明迭代器块可以多么有用。

[英]Jon Skeet. 深入理解C#(第3版) (图灵程序设计丛书) (Kindle 位置 4848-4852). 人民邮电出版社. Kindle 版本.

w343516704

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
C#学习笔记（三）—–C#高级特性：实现迭代器的捷径

实现迭代器的捷径本章摘自《C# in depth》，内容包括：在C#1中实现迭代器 C#中的迭代器块迭代器使用示例使用迭代器作为协同程序迭代器模式是行为模式的一种范例，行为模式是一种简化对象之间通信的设计模式。这是一种非常易于理解和使用的模式。实际上，它允许你访问一个数据项序列中的所有元素，而无须关心
复制链接

扫一扫