迭代器模式是設計模式中行為模式(behavioral pattern)的一個例子，他是一種簡化對象間通訊的模式，也是一種非常容易理解和使用的模式。簡單來說，迭代器模式使得你能夠獲取到序列中的所有元素而不用關心是其類型是array，list，linked list或者是其他什麼序列結構。這一點使得能夠非常高效的構建數據處理通道(data pipeline)--即數據能夠進入處理通道，進行一系列的變換，或者過濾，然後得到結果。事實上，這正是LINQ的核心模式。
在.NET中，迭代器模式被IEnumerator和IEnumerable及其對應的泛型接口所封裝。如果一個類實現了IEnumerable接口，那麼就能夠被迭代；調用GetEnumerator方法將返回IEnumerator接口的實現，它就是迭代器本身。迭代器類似數據庫中的游標，他是數據序列中的一個位置記錄。迭代器只能向前移動，同一數據序列中可以有多個迭代器同時對數據進行操作。
在C#1中已經內建了對迭代器的支持，那就是foreach語句。使得能夠進行比for循環語句更直接和簡單的對集合的迭代，編譯器會將foreach編譯來調用GetEnumerator和MoveNext方法以及Current屬性，如果對象實現了IDisposable接口，在迭代完成之後會釋放迭代器。但是在C#1中，實現一個迭代器是相對來說有點繁瑣的操作。C#2使得這一工作變得大為簡單，節省了實現迭代器的不少工作。
接下來，我們來看如何實現一個迭代器以及C#2對於迭代器實現的簡化，然後再列舉幾個迭代器在現實生活中的例子。
1. C#1:手動實現迭代器的繁瑣
假設我們需要實現一個基於環形緩沖的新的集合類型。我們將實現IEnumerable接口，使得用戶能夠很容易的利用該集合中的所有元素。我們的忽略其他細節，將注意力僅僅集中在如何實現迭代器上。集合將值存儲在數組中，集合能夠設置迭代的起始點，例如，假設集合有5個元素，你能夠將起始點設為2，那麼迭代輸出為2，3，4，0，最後是1.
為了能夠簡單展示，我們提供了一個設置值和起始點的構造函數。使得我們能夠以下面這種方式遍歷集合：
object[] values = {"a", "b", "c", "d", "e"};
IterationSample collection = new IterationSample(values, 3);
foreach (object x in collection)
{
Console.WriteLine (x);
}
由於我們將起始點設置為3，所以集合輸出的結果是d,e,a,b及c，現在，我們來看如何實現 IterationSample 類的迭代器：
class IterationSample:IEnumerable
{
Object[] values;
Int32 startingPoint;
public IterationSample(Object[] values, Int32 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#中的內部類來實現這一邏輯。代碼如下：
class IterationSampleEnumerator : IEnumerator
{
IterationSample parent;//迭代的對象 #1
Int32 position;//當前游標的位置 #2
internal IterationSampleEnumerator(IterationSample parent)
{
this.parent = parent;
position = -1;// 數組元素下標從0開始，初始時默認當前游標設置為 -1，即在第一個元素之前， #3
}
public bool MoveNext()
{
if (position != parent.values.Length) //判斷當前位置是否為最後一個，如果不是游標自增 #4
{
position++;
}
return position < parent.values.Length;
}
public object Current
{
get {
if (position == -1 || position == parent.values.Length)//第一個之前和最後一個自後的訪問非法 #5
{
throw new InvalidOperationException();
}
Int32 index = position + parent.startingPoint;//考慮自定義開始位置的情況 #6
index = index % parent.values.Length;
return parent.values[index];
}
}
public void Reset()
{
position=-1;//將游標重置為-1 #7
}
}
要實現一個簡單的迭代器需要手動寫這麼多的代碼：需要記錄迭代的原始集合#1，記錄當前游標位置#2，返回元素時，根據當前游標和數組定義的起始位置設置定迭代器在數組中的位置#6。初始化時，將當前位置設定在第一個元素之前#3，當第一次調用迭代器時首先需要調用MoveNext，然後再調用Current屬性。在游標自增時對當前位置進行條件判斷#4，使得即使當第一次調用MoveNext時沒有可返回的元素也不至於出錯#5。重置迭代器時，我們將當前游標的位置還原到第一個元素之前#7。
除了結合當前游標位置和自定義的起始位置返回正確的值這點容易出錯外，上面的代碼非常直觀。現在，只需要在IterationSample類的GetEnumerator方法中返回我們當才編寫的迭代類即可：
public IEnumerator GetEnumerator()
{
return new IterationSampleEnumerator(this);
}
值得注意的是，上面只是一個相對簡單的例子，沒有太多的狀態需要跟蹤，不用檢查集合在迭代的過程中是否發生了變化。為了實現一個簡單的迭代器，在C#1中我們實現了如此多的代碼。在使用Framework自帶的實現了IEnumerable接口的集合時我們使用foreach很方便，但是當我們書寫自己的集合來實現迭代時需要編寫這麼多的代碼。
在C#1中，大概需要40行代碼來實現一個簡單的迭代器，現在看看C#2對這一過程的改進。
2. C#2:通過yield語句簡化迭代
2.1 引入迭代塊(iterator)和yield return 語句
C#2使得迭代變得更加簡單--減少了很多代碼量也使得代碼更加的優雅。下面的代碼展示了再C#2中實現GetEnumerator方法的完整代碼：
public IEnumerator GetEnumerator()
{
for (int index = 0; index < this.values.Length; index++)
{
yield return values[(index + startingPoint) % values.Length];
}
}
簡單幾行代碼就能夠完全實現IterationSampleIterator類所需要的功能。方法看起來很普通，除了使用了yield return。這條語句告訴編譯器這不是一個普通的方法，而是一個需要執行的迭代塊（yield block），他返回一個IEnumerator對象，你能夠使用迭代塊來執行迭代方法並返回一個IEnumerable需要實現的類型，IEnumerator或者對應的泛型。如果實現的是非泛型版本的接口，迭代塊返的yield type是Object類型，否則返回的是相應的泛型類型。例如，如果方法實現IEnumerable<String>接口，那麼yield返回的類型就是String類型。
在迭代塊中除了yield return外，不允許出現普通的return語句。塊中的所有yield return 語句必須返回和塊的最後返回類型兼容的類型。舉個例子，如果方法定義需要返回IEnumeratble<String>類型的話，不能yield return 1 。
需要強調的一點是，對於迭代塊，雖然我們寫的方法看起來像是在順序執行，實際上我們是讓編譯器來為我們創建了一個狀態機。這就是在C#1中我們書寫的那部分代碼---調用者每次調用只需要返回一個值，因此我們需要記住最後一次返回值時，在集合中位置。
當編譯器遇到迭代塊是，它創建了一個實現了狀態機的內部類。這個類記住了我們迭代器的准確當前位置以及本地變量，包括參數。這個類有點類似與我們之前手寫的那段代碼，他將所有需要記錄的狀態保存為實例變量。下面來看看，為了實現一個迭代器，這個狀態機需要按順序執行的操作：
• 它需要一些初始的狀態
• 當MoveNext被調用時，他需要執行GetEnumerator方法中的代碼來准備下一個待返回的數據。
• 當調用Current屬性是，需要返回yielded的值。
• 需要知道什麼時候迭代結束是，MoveNext會返回false
下面來看看迭代器的執行順序。
2.2 迭代器的執行流程
如下的代碼，展示了迭代器的執行流程，代碼輸出(0,1,2,-1)然後終止。
class Program
{
static readonly String Padding=new String(' ',30);
static IEnumerable<Int32> CreateEnumerable()
{
Console.WriteLine("{0} CreateEnumerable()方法開始",Padding);
for (int i = 0; i < 3; i++)
{
Console.WriteLine("{0}開始 yield {1}",i);
yield return i;
Console.WriteLine("{0}yield 結束",Padding);
}
Console.WriteLine("{0} Yielding最後一個值",Padding);
yield return -1;
Console.WriteLine("{0} CreateEnumerable()方法結束",Padding);
}
static void Main(string[] args)
{
IEnumerable<Int32> iterable=CreateEnumerable();
IEnumerator<Int32> iterator=iterable.GetEnumerator();
Console.WriteLine("開始迭代");
while(true){
Console.WriteLine("調用MoveNext方法……");
Boolean result=iterator.MoveNext();
Console.WriteLine("MoveNext方法返回的{0}",result);
if (!result)
{
break;
}
Console.WriteLine("獲取當前值……");
Console.WriteLine("獲取到的當前值為{0}",iterator.Current);
}
Console.ReadKey();
}
}
為了展示迭代的細節，以上代碼使用了while循環，正常情況下一般使用foreach。和上次不同，這次在迭代方法中我們返回的是IEnumerable<int>對象而不是IEnumerator<int>對象。通常，為了實現IEnumerable<T>接口，只需要返回IEnumerator<T>對象即可；如果自是想從一個方法中返回一些列的數據，那麼使用IEnumerable<T>.
以下是輸出結果：
從輸出結果中可以看出一下幾點：
• 直到第一次調用MoveNext，CreateEnumerable中的方法才被調用。
• 在調用MoveNext的時候，已經做好了所有操作，返回Current屬性並沒有執行任何代碼。
• 代碼在yield return之後就停止執行，等待下一次調用MoveNext方法的時候繼續執行。
• 在方法中可以有多個yield return語句。
• 在最後一個yield return執行完成後，代碼並沒有終止。調用MoveNext返回false使得方法結束。
第一點尤為重要：這意味著，不能在迭代塊中寫任何在方法調用時需要立即執行的代碼--比如說參數驗證。如果將參數驗證放在迭代塊中，那麼他將不能夠很好的起作用，這是經常會導致的錯誤的地方，而且這種錯誤不容易發現。
下面來看如何停止迭代，以及finally語句塊的特殊執行方式。
2.3 迭代器的特殊執行流程
在普通的方法中，return語句通常有兩種作用，一是返回調用者執行的結果。二是終止方法的執行，在終止之前執行finally語句中的方法。在上面的例子中，我們看到了yield return語句只是短暫的退出了方法，在MoveNext再次調用的時候繼續執行。在這裡我們沒有寫finally語句塊。如何真正的退出方法，退出方法時finnally語句塊如何執行，下面來看看一個比較簡單的結構：yield break語句塊。
使用 yield break 結束一個迭代
通常我們要做的是使方法只有一個退出點，通常，多個退出點的程序會使得代碼不易閱讀，特別是使用try catch finally等語句塊進行資源清理以及異常處理的時候。在使用迭代塊的時候也會遇到這樣的問題，但如果你想早點退出迭代，那麼使用yield break就能達到想要的效果。他能夠馬上終止迭代，使得下一次調用MoveNext的時候返回false。
下面的代碼演示了從1迭代到100，但是時間超時的時候就停止了迭代。
static IEnumerable<Int32> CountWithTimeLimit(DateTime limit)
{
try
{
for (int i = 1; i <= 100; i++)
{
if (DateTime.Now >= limit)
{
yield break;
}
yield return i;
}
}
finally
{
Console.WriteLine("停止迭代！");
Console.ReadKey();
}
}
static void Main(string[] args)
{
DateTime stop = DateTime.Now.AddSeconds(2);
foreach (Int32 i in CountWithTimeLimit(stop))
{
Console.WriteLine("返回 {0}", i);
Thread.Sleep(300);
}
}
下圖是輸出結果，可以看出迭代語句正常終止，yield return語句和普通方法中的return語句一樣，下面來看看finally語句塊是什麼時候以及如何執行的。
Finally語句塊的執行
通常，finally語句塊在當方法執行退出特定區域時就會執行。迭代塊中的finally語句和普通方法中的finally語句塊不一樣。就像我們看到的，yield return語句停止了方法的執行，而不是退出方法，根據這一邏輯，在這種情況下，finally語句塊中的語句不會執行。
但當碰到yield break語句的時候，就會執行finally 語句塊，這根普通方法中的return一樣。一般在迭代塊中使用finally語句來釋放資源，就像使用using語句一樣。
下面來看finally語句如何執行。
不管是迭代到了100次或者是由於時間到了停止了迭代，或者是拋出了異常，finally語句總會執行，但是在有些情況下，我們不想讓finally語句塊被執行。
只有在調用MoveNext後迭代塊中的語句才會執行，那麼如果不掉用MoveNext呢，如果調用幾次MoveNext然後停止調用，結果會怎麼樣呢？請看下面的代碼？
DateTime stop = DateTime.Now.AddSeconds(2);
foreach (Int32 i in CountWithTimeLimit(stop))
{
if (i > 3)
{
Console.WriteLine("返回中^");
return;
}
Thread.Sleep(300);
}
在forech中，return語句之後，因為CountWithTimeLimit中有finally塊所以代碼繼續執行CountWithTimeLimit中的finally語句塊。foreach語句會調用GetEnumerator返回的迭代器的Dispose方法。在結束迭代之前調用包含迭代塊的迭代器的Dispose方法時，狀態機會執行在迭代器范圍內處於暫停狀態下的代碼范圍內的所有finally塊，這有點復雜，但是結果很容易解釋：只有使用foreach調用迭代，迭代塊中的finally塊會如期望的那樣執行。下面可以用代碼驗證以上結論：
IEnumerable<Int32> iterable = CountWithTimeLimit(stop);
IEnumerator<Int32> iterator = iterable.GetEnumerator();
iterator.MoveNext();
Console.WriteLine("返回 {0}", iterator.Current);
iterator.MoveNext();
Console.WriteLine("返回 {0}", iterator.Current);
Console.ReadKey();
代碼輸出如下：
上圖可以看出，停止迭代沒有打印出來，當我們手動調用iterator的Dispose方法時，會看到如下的結果。在迭代器迭代結束前終止迭代器的情況很少見，也很少不使用foreach語句而是手動來實現迭代，如果要手動實現迭代，別忘了在迭代器外面使用using語句，以確保能夠執行迭代器的Dispose方法進而執行finally語句塊。
下面來看看微軟對迭代器的一些實現中的特殊行為：
2.4 迭代器執行中的特殊行為
如果使用C#2的編譯器將迭代塊編譯，然後使用ildsam或者Reflector查看生成的IL代碼，你會發現在幕後編譯器回味我們生成了一些嵌套的類型(nested type).下圖是使用Ildsam來查看生成的IL ,最下面兩行是代碼中的的兩個靜態方法，上面藍色的<CountWithTimeLimit>d_0是編譯器為我們生成的類(尖括號只是類名，和泛型無關)，代碼中可以看出該類實現了那些接口，以及有哪些方法和字段。大概和我們手動實現的迭代器結構類似。
真正的代碼邏輯實在MoveNext方法中執行的，其中有一個大的switch語句。幸運的是，作為一名開發人員沒必要了解這些細節，但一些迭代器執行的方式還是值得注意的：
• 在MoveNext方法第一次執行之前，Current屬性總是返回迭代器返回類型的默認的值。例如IEnumeratble返回的是Int32類型，那麼默認初始值是0，所以在調用MoveNext方法之前調用Current屬性就會返回0。
• MoveNext方法返回false後，Current屬性總是返回最後迭代的那個值。
• Reset方法一般會拋出異常，而在本文開始代碼中，我們手動實現一個迭代器時在Reset中能夠正確執行邏輯。
• 編譯器為我們產生的嵌套類會同時實現IEnumerator的泛型和非泛型版本(恰當的時候還會實現IEnumerable的泛型和非泛型版本).
沒有正確實現Reset方法是有原因的--編譯器不知道需要使用怎樣的邏輯來從新設置迭代器。很多人認為不應該有Reset方法，很多集合並不支持，因此調用者不應該依賴這一方法。
實現其它接口沒有壞處。方法中返回IEnumerable接口，他實現了五個接口(包括IDisposable)，作為一個開發者不用擔心這些。同時實現IEnumerable和IEnumerator接口並不常見，編譯器為了使迭代器的行為總是正常，並且為能夠在當前的線程中僅僅需要迭代一個集合就能創建一個單獨的嵌套類型才這麼做的。
Current屬性的行為有些古怪，他保存了迭代器的最後一個返回值並且阻止了垃圾回收期進行收集。
因此，自動實現的迭代器方法有一些小的缺陷，但是明智的開發者不會遇到任何問題，使用他能夠節省很多代碼量，使得迭代器的使用程度比C#1中要廣。下面來看在實際開發中迭代器簡化代碼的地方。
3.實際開發中使用迭代的例子
3.1 從時間段中迭代日期
在涉及到時間區段時，通常會使用循環，代碼如下：
for (DateTime day = timetable.StartDate; day < timetable.EndDate; day=day.AddDays(1))
{
……
}
循環有時沒有迭代直觀和有表現力，在本例中，可以理解為“時間區間中的每一天”，這正是foreach使用的場景。因此上述循環如果寫成迭代，代碼會更美觀：
foreach(DateTime day in timetable.DateRange)
{
……
}
在C#1.0中要實現這個需要下一定功夫。到了C#2.0就變得簡單了。在timetable類中，只需要添加一個屬性：
public IEnumerable<DateTime> DateRange
{
get
{
for (DateTime day=StartDate ; day < =EndDate; day=day.AddDays(1))
{
yield return day;
}
}
}
只是將循環移動到了timetable類的內部，但是經過這一改動，使得封裝變得更為良好。DateRange屬性只是遍歷時間區間中的每一天，每一次返回一天。如果想要使得邏輯變得復雜一點，只需要改動一處。這一小小的改動使得代碼的可讀性大大增強，接下來可以考慮將這個Range擴展為泛型Range<T>。
3.2迭代讀取文件中的每一行
讀取文件時，我們經常會書寫這樣的代碼：
using (TextReader reader=File.OpenText(fileName))
{
String line;
while((line=reader.ReadLine())!=null)
{
……
}
}
這一過程中有4個環節：
• 如何獲取TextReader
• 管理TextReader的生命周期
• 通過TextReader.ReadLine迭代所有的行
• 對行進行處理
可以從兩個方面對這一過程進行改進:可以使用委托--可以寫一個擁有reader和一個代理作為參數的輔助方法，使用代理方法來處理每一行，最後關閉reader，這經常被用來展示閉包和代理。還有一種更為優雅更符合LINQ方式的改進。除了將邏輯作為方法參數傳進去，我們可以使用迭代來迭代一次迭代一行代碼，這樣我們就可以使用foreach語句。代碼如下：
static IEnumerable<String> ReadLines(String fileName)
{
using ( TextReader reader=File.OpenText(fileName))
{
String line;
while ((line=reader.ReadLine())!=null)
{
yield return line;
}
}
}
這樣就可以使用如下foreach方法來讀取文件了：
foreach (String line in ReadLines("test.txt"))
{
Console.WriteLine(line);
}
方法的主體部分和之前的一樣，使用yield return返回了讀取到的每一行，只是在迭代結束後有點不同。之前的操作，先打開文檔，每一次讀取一行，然後在讀取結束時關閉reader。雖然”當讀取結束時”和之前方法中使用using相似，但當使用迭代時這個過程更加明顯。
這就是為什麼foreach迭代結束後會調用迭代器的dispose方法這麼重要的原因了，這個操作能夠保證reader能夠得到釋放。迭代方法中的using語句塊類似與try/finally語句塊；finally語句在讀取文件結束或者當我們顯示調用IEnumerator<String> 的Dispose方法時都會執行。可能有時候會通過ReadLine().GetEnumerator()的方式返回IEnumerator<String> ，進行手動迭代而沒有調用Dispose方法，就會產生資源洩漏。通常會使用foreach語句來迭代循環，所以這個問題很少會出現。但是還是有必要意識到這個潛在的問題。
該方法封裝了前三個步驟，這可能有點苛刻。將生命周期和方法進行封裝是有必要的，現在擴展一下，假如我們要從網絡上讀取一個流文件，或者我們想使用UTF-8編碼的方法，我們需要將第一個部分暴漏給方法調用者，使得方法的調用簽名大致如下：
static IEnumerable<String> ReadLines(TextReader reader)
這樣有很多不好的地方，我們想對reader有絕對的控制，使得調用者能夠在結束後能進行資源清理。問題在於，如果在第一次調用MoveNext()之前出現錯誤，那麼我們就沒有機會進行資源清理工作了。IEnumerable<String>自身不能釋放，他存儲了某個狀態需要被清理。另一個問題是如果GetEnumerator被調用兩次，我們本意是返回兩個獨立的迭代器，然後他們卻使用了相同的reader。一種方法是，將返回類型改為IEnumerator<String>,但這樣的話，不能使用foreach進行迭代，而且如果沒有執行到MoveNext方法的話，資源也得不到清理。
幸運的是，有一種方法可以解決以上問題。就像代碼不必立即執行，我們也不需要reader立即執行。我們可以提供一個接口實現“如果需要一個TextReader，我們可以提供”。在.NET 3.5中有一個代理，簽名如下：
public delegate TResult Func<TResult>()
代理沒有參數，返回和類型參數相同的類型。我們想獲得TextReader對象，所以可以使用Func<TextReader>，代碼如下：
using (TextReader reader=provider())
{
String line;
while ((line=reader.ReadLine())!=null)
{
yield return line;
}
}
3.3 使用迭代塊和迭代條件來對集合進行進行惰性過濾
LINQ允許對內存集合或者數據庫等多種數據源用簡單強大的方式進行查詢。雖然C#2沒有對查詢表達式，lambda表達及擴展方法進行集成。但是我們也能達到類似的效果。
LINQ的一個核心的特征是能夠使用where方法對數據進行過濾。提供一個集合以及過濾條件代理，過濾的結果就會在迭代的時候通過惰性匹配，每匹配一個過濾條件就返回一個結果。這有點像List<T>.FindAll方法，但是LINQ支持對所有實現了IEnumerable<T>接口的對象進行惰性求值。雖然從C#3開始支持LINQ，但是我們也可以使用已有的知識在一定程度上實現LINQ的Where語句。代碼如下：
public static IEnumerable<T> Where<T>(IEnumerable<T> source, Predicate<T> predicate)
{
if (source == null || predicate == null)
throw new ArgumentNullException();
return WhereImpl(source, predicate);
}
private static IEnumerable<T> WhereImpl<T>(IEnumerable<T> source, Predicate<T> predicate)
{
foreach (T item in source)
{
if (predicate(item))
yield return item;
}
}
IEnumerable<String> lines = ReadLines("FakeLinq.cs");
Predicate<String> predicate = delegate(String line)
{
return line.StartsWith("using");
};
如上代碼中，我們將整個實現分為了兩個部分，參數驗證和具體邏輯。雖然看起來奇怪，但是對於錯誤處理來說是很有必要的。如果將這兩個部分方法放到一個方法中，如果用戶調用了Where<String>(null,null)，將不會發生任何問題，至少我們期待的異常沒有拋出。這是由於迭代塊的惰性求值機制產生的。在用戶迭代的時候第一次調用MoveNext方法之前，方法主體中的代碼不會執行，就像在2.2節中看到的那樣。如果你想急切的對方法的參數進行判斷，那麼沒有一個地方能夠延緩異常，這使得bug的追蹤變得困難。標准的做法如上代碼，將方法分為兩部分，一部分像普通方法那樣對參數進行驗證，另一部分代碼使用迭代塊對主體邏輯數據進行惰性處理。
迭代塊的主體很直觀，對集合中的逐個元素，使用predict代理方法進行判斷，如果滿足條件，則返回。如果不滿足條件，則迭代下一個，直到滿足條件為止。如果要在C#1中實現這點邏輯就很困難，特別是實現其泛型版本。
後面的那段代碼演示了使用之前的readline方法讀取數據然後用我們的where方法來過濾獲取line中以using開頭的行，和用File.ReadAllLines及Array.FindAll<String>實現這一邏輯的最大的差別是，我們的方法是完全惰性和流線型的(Streaming)。每一次只在內存中請求一行並對其進行處理，當然如果文件比較小的時候沒有什麼差別，但是如果文件很大，例如上G的日志文件，這種方法的優勢就會顯現出來了。
4 總結
C#對許多設計模式進行了間接的實現，使得實現這些模式變得很容易。相對來針對某一特定的設計模式直接實現的的特性比較少。從foreach代碼中看出，C#1對迭代器模式進行了直接的支持，但是沒有對進行迭代的集合進行有效的支持。對集合實現一個正確的IEnumerable很耗時，容易出錯也很很枯燥。在C#2中，編譯器為我們做了很多工作，為我們實現了一個狀態機來實現迭代。
本文還展示了和LINQ相似的一個功能：對集合進行過濾。IEnumerable<T>在LINQ中最重要的一個接口，如果想要在LINQ To Object上實現自己的LINQ操作，那麼你會由衷的感歎這個接口的強大功能以及C#語言提供的迭代塊的用處。
本文還展示了實際項目中使用迭代塊使得代碼更加易讀和邏輯性更好的例子，希望這些例子使你對理解迭代有所幫助。
摘自 無花無酒鋤作田
