淺談C#的文法特性及雜七雜八

園子裡的首頁已經在所謂的C#大論戰和語言大作戰上，風風火火地持續了快一個月了，我想也該告上那麼一段落了。

我只在這裡寫下我眼中的看法。

1. C#的文法糖

在之前，每當別人問起我，某個C#的新語言特性的時候，我總會說，其實就是這麼一回事，他不過是一個文法糖，沒什麼稀奇的，你可以看一下Reflector反編譯出來的代碼。

可是現在當我仔細思考之後，發現其實文法糖更多地不僅僅是為了我們使用上的方便，而且是代表了一種編程模式以及思維模式的轉變。

從最簡單地說起，我在之前的文章說過一點，面向過程的語言的核心不在於函數，而在於處理事情的過程，而函數則完全是為了代碼的規範，以及可維護性才出現的。但是當我們把若干個函數整理成了我們的類庫之後，我們除了使用上方便之外，更意味著我們需要提高我們的邏輯層次，將原本的細粒度邏輯粗化。

我看到了在winter-cn的文章中舉了這樣一個例子，把大象放入冰箱分成幾步，第一第二第三，Ivovy老大回複了這樣一句話，語言的發展是讓這些都變成一步：把大象裝入冰箱。我非常贊同，我認為這就是未來語言的發展方向。

在我之前的文章《基於自然語言的軟體工程與程式設計》中，我談到未來語言的發展方向是基於自然語言的編程，還談到了一種理想的狀況，就是會說話的人就會寫程式。即使我們不把眼光放得這麼遠，我認為，只要瞭解商務邏輯的人就會編程，這個是完全不過分的。

接下來，我們看一個在C# 3.0 中的關鍵字：var。在之前，很多人說var最大的作用是為了讓懶的人可以不必去打字打出類型。其實我個人更認為當var關鍵字和我們強大的Visual Studio工具結合起來的時候，就在倡導我們用一種團隊思維的角度去看待問題。

當我們調用底層提供給我們的介面，或者使用其他類庫返回給我們的方法時，我們不需要瞭解他的具體類型，我們只需要用var來得到該類型，然後用強大的VS開發工具的智能感知去得到我們需要的屬性（或方法）即可。

至於像Lambda運算式所提倡的FP思維，我就更不多說了。

總之，Firelong眼中說，C#語言越來越臃腫的語言特性，然後應該越來越從簡，我個人認為，這不是在抹殺C#的進步，更關鍵的是在抹殺一種編程思維的進步。

2. 語言，還是語言

在語言產生之初，語言之爭似乎就從未停止。無論是C和C++。還是Java與C#。從來都是各執一詞，然後難分勝負。

我不是一個牛人，無法像Jeffery Zhao一樣來舉出各種各樣的理由來反對Java，或者反對其他語言。至少在我目前的階段來看，我不是一個語言方面的攻擊者。

我只能從經濟學的角度去分析：每門語言，每門流行的語言，在市場上佔有一定份額的語言，必定有著他的優勢所在，否則他必定會被市場所淘汰。而每門語言也必然有著他的劣勢，和不適用性，正是這樣才催生了其他語言的發展，從而產生一種平衡的關係。

在這裡，我只說託管語言。從某種程度上，至少從我目前的程度上，我認為，託管語言來開發傳統型程式的確是不大合適的，相對於C++。（在此強調，我並沒有過太多傳統型程式開發的經驗）針對當前大多數的商業商品來說，無論是舊版的飛信，還是概念版的QQ，採用託管語言無疑都是失敗的，而我們看大部分成熟的傳統型程式，還是採用C++來開發，這確實也能說明一定道理。

而著名的《鬼泣4》採用C++和C#做互動來共同開發，也在一定程式上說明了C#在UI上的薄弱性。（只是看新聞傳說，未經證實）

總之，我個人認為：不要輕易地去抨擊某一門語言，每門語言都有著他的適用性，你的項目因為C#而失敗，只能說是你項目不該選擇C#，而不能說C#無法滿足你的項目，就說C#是失敗的。這樣的邏輯明顯就是不對的。

3. 語言與設計模式

在之前的文章中，我拋出過這樣的一個觀點：設計模式實際上是犧牲了語義的自然性，來換取軟體的可重用性和可維護性。

對於C#這樣一門物件導向的語言而言，根本還是要從物件導向來出發，那麼物件導向的核心是什嗎？每個類都有章可循。

但是，在很多的時候，我們為了擴充性，重用性，可維護性，不得不求助於GOF或者其他的設計模式，我個人認為，設計模式是凸顯了“語言”的無助。

因而，在語言的層面上融入設計模式，我個人認為，這不是一種錯誤，相反，這卻是語言發展的必然，至少是基於物件導向語言發展的必然。到物件導向語言發展到極致的時候，應該是一種我們不需要藉助設計模式，只要依靠語言提供給我們的文法（或者是”文法糖“）就足夠完成我們用其他的設計模式可以完成的工作，這才是物件導向語言發展的大成。

再進一步地說，沒有任何一門編程模式是銀彈，可以解決我們的所有問題，無論是物件導向，面向過程，還是FP，一種發展逐漸完善的語言應該是將各種編程模式於一體，提供給程式員一種極高的思維抽象，這才是未來語言的方向。