C#學習筆記（三）—–C#高級特性：實現迭代器的捷徑

實現迭代器的捷徑

本章摘自《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 版本.

C#學習筆記（三）—–C#高級特性：實現迭代器的捷徑

實現迭代器的捷徑

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

C# 2：利用 yield 語句簡化迭代器

觀察迭代器的工作流程

進一步瞭解迭代器執行流程

具體實現中的奇特之處

真實的迭代器示例

C#學習筆記（三）—–C#高級特性：實現迭代器的捷徑

C#學習筆記（七）—–集合--Array

C#學習筆記（八）—–LINQ查詢創建策略

C#學習筆記（八）—–LinqToSql和Entity Framework（上）

C#學習筆記（八）—–LINQ查詢的基礎知識（下）

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

C#學習筆記（三）—–C#高級特性：實現迭代器的捷徑

實現迭代器的捷徑

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

C# 2： 利用 yield 語句 簡化 迭代 器

觀察 迭代 器 的 工作 流程

進一步 瞭解 迭代 器 執行 流程

具體 實現 中的 奇特 之處

真實 的 迭代 器 示例

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

C# 2：利用 yield 語句簡化迭代器

觀察迭代器的工作流程

進一步瞭解迭代器執行流程

具體實現中的奇特之處

真實的迭代器示例