C#2.0之殤，以及函數式編程的未來
似乎還有不少項目在用C#2.0，但是C#2.0的生產力實在不如C#3.0——如果您不信，那么一會兒就會意識到這一點。有朋友認為語言能力不重要，有了好用的框架/類庫也可以有很高的生產力。所以這篇文章，我們就設法使用“類庫”來彌補C#2.0的缺陷。
但是，我們真做的到嗎？
C#2.0之殤
C#2.0較C#1.0來說是一個突破，其中引入了泛型，以及匿名方法等新特性。如果前者還可以說是平臺的增強，而語言只是個“輔助”的話，而后者則百分之一百是編譯器的魔法了。別小看這個特性，它為C#3.0的高生產力踏出了堅實的一步——不過還是差了很多。例如，我們有一個要求：“把一個字符串數組中的元素轉化為整數，再將其中的偶數放入一個List< int>容器中”。如果是C#3.0，這是再簡單不過的功能：
- string[]strArray={"1","2","3","4"};
- vareven=strArray.Select(s=>Int32.Parse(s)).Where(i=>i%2==0).ToList();
那么對于C#2.0（當然對于C#1.0也一樣），代碼又該怎么寫呢？
- List< int>even=newList< int>();
- foreach(stringsinstrArray)
- {
- inti=Int32.Parse(s);
- if(i%2==0)
- {
- even.Add(i);
- }
- }
有人說函數式編程有什么用，C#3.0就是個很好的證明。C#3.0中引入了Lambda表達式，增強了在語言中構造匿名方法的能力——這是一個語言中函數式編程特性的必備條件。C#3.0的實現與C#2.0相比，可讀性高，可以直接看出轉化、過濾，以及構造容器的過程和標準。由于語言能力的增強，程序的表現能力得到了很大的提高，在很多時候，我們可以省去將一些代碼提取為獨立方法的必要。當然，即使您將其提取為額外的方法，C#3.0也可以讓您寫出更少的代碼。
如果您覺得以上代碼的差距還不是過于明顯的話——那么以下功能呢？
- int[]intArray={1,2,3,4,5,6,7,8,9,10};
- //所有偶數的平均數
- varevenAverage=intArray.Where(i=>i%2==0).Average();
- //都是偶數？
- varallEven=intArray.All(i=>i%2==0);
- //包含偶數？
- varcontainsEven=intArray.Any(i=>i%2==0);
- //第4到第8個數
- varfourthToEighth=intArray.Skip(3).Take(5);
如果您使用C#2.0來寫，您會怎么做？
拯救C#2.0
C#3.0通過引入了函數式編程特性大幅增強了語言的生產力。如果說C#2.0和Java還沒有太大差距的話，那么C#3.0已經將Java甩開地太遠太遠。不過真要說起來，在Java中并非不可以加入函數式編程的理念。只不過，如果沒有足夠的語言特性進行支持（如快速構造匿名函數、閉包、一定程度的類型推演等等），函數式編程對于某些語言來說幾乎只能成為“理念”。不過現在，我們暫且先放下對“函數式編程”相關內容的探索，設法拯救C#2.0所缺失的生產力吧。
C#3.0中可以使用Lambda表達式構造一個匿名函數，這個能力其實在C#2.0中也有。我們姑且認為這點不是造成差距的主要原因，那么有一點是C#2.0絕對無法實現的，那就是“擴展方法”。C#3.0中的擴展方法，可以“零耦合”地為一個，甚至一系列類型添加“實例方法”。當然，這也是編譯器的功能，實際上我們只是定義了一些靜態方法而已。這一點在C#2.0中還是可以做到的：
- publicclassEnumerable
- {
- publicstaticIEnumerable< T>Where< T>(Func< T,bool>predicate,IEnumerable< T>source)
- {
- foreach(Titeminsource)
- {
- if(predicate(item))
- {
- yieldreturnitem;
- }
- }
- }
- publicstaticIEnumerable< TResult>Select< T,TResult>(Func< T,TResult>selector,IEnumerable< T>source)
- {
- foreach(Titeminsource)
- {
- yieldreturnselector(item);
- }
- }
- publicstaticList< T>ToList< T>(IEnumerable< T>source)
- {
- List< T>list=newList< T>();
- foreach(Titeminsource)
- {
- list.Add(item);
- }
- returnlist;
- }
- }
于是現在，我們便可以換種寫法來實現相同的功能了：
- string[]strArray={"1","2","3","4"};
- List< int>even=
- Enumerable.ToList(
- Enumerable.Where(
- delegate(inti){returni%2==0;},
- Enumerable.Select(
- delegate(strings){returnInt32.Parse(s);},
- strArray)));
即使您可以接受delegate關鍵字構造匿名函數的能力，但是上面的做法還是有個天生的缺陷：邏輯與表現的次序想反。我們想表現的邏輯順序為：轉化（Select）、過濾（Where）、及容器構造（ToList），C#3.0所表現出的順序和它相同，而C#2.0的順序則相反。由于語言能力的缺失，這個差距無法彌補。很多時候，語言的一些“小功能”并不能說是可有可無的特性，它很可能直接決定了是否可以用某種語言來構造InternalDSL或進行BDD。例如，由于F#的靈活語法，FsTest使得開發人員可以寫出"foobar"|>shouldcontains"foo"這樣的語句來避免機械的Assert語法。同樣，老趙也曾經使用actor< =msg這樣的邏輯來替代actor.Post(msg)的顯式調用方式。
封裝邏輯
既然沒有“擴展方法”，我們要避免靜態方法的調用形式，那么就只能在一個類中定義邏輯了。這點并不困難，畢竟在API的設計發展至今，已經進入了關注FluentInterface的階段，這方面已經積累了大量的實踐。于是我們構造一個Enumerable< T>類，封裝IEnumerable< T>對象，以此作為擴展的入口：
- publicclassEnumerable< T>
- {
- privateIEnumerable< T>m_source;
- publicEnumerable(IEnumerable< T>source)
- {
- if(source==null)thrownewArgumentNullException("source");
- this.m_source=source;
- }
- ...
- }
- 并以此定義所需的Select和Where方法：
- publicEnumerable< T>Where(Func< T,bool>predicate)
- {
- if(predicate==null)thrownewArgumentNullException("predicate");
- returnnewEnumerable< T>(Where(this.m_source,predicate));
- }
- privatestaticIEnumerable< T>Where(IEnumerable< T>source,Func< T,bool>predicate)
- {
- foreach(Titeminsource)
- {
- if(predicate(item))
- {
- yieldreturnitem;
- }
- }
- }
- publicEnumerable< TResult>Select< TResult>(Func< T,TResult>selector)
- {
- if(selector==null)thrownewArgumentNullException("selector");
- returnnewEnumerable< TResult>(Select(this.m_source,selector));
- }
- privatestaticIEnumerable< TResult>Select< TResult>(IEnumerable< T>source,Func< T,TResult>selector)
- {
- foreach(Titeminsource)
- {
- yieldreturnselector(item);
- }
- }
這些擴展都是些高階函數，也都有延遲效果，相信很容易理解，在此就不多作解釋了。在這里我們直接觀察其使用方式：
- List< int>even=newEnumerable< string>(strArray)
- .Select(delegate(strings){returnInt32.Parse(s);})
- .Where(delegate(inti){returni%2==0;})
- .ToList();
不知道您對此有何感覺？
老趙對此并不滿意，尤其是和C#3.0相較之下。我們雖然定義了Enumerable封裝類，并提供了Select和Where等邏輯，但是由于匿名函數的構造還是較為丑陋。使用delegate構造匿名函數還是引起了不少噪音：
與JavaScript的function關鍵字，和VB.NET的Function關鍵字一樣，C#2.0在構造匿名函數時無法省確delegate關鍵字。
與C#3.0中的Lambda表達式相比，使用delegate匿名函數缺少了必要的類型推演。
使用delegate構造匿名函數時必須提供完整的方法體，也就是只能提供“語句”，而不能僅為一個“表達式”，因此return和最后的分號無法省確。
我們設法拯救C#2.0，但是我們真的做到了嗎？
框架/類庫真能彌補語言的生產力嗎？
【編輯推薦】
