1. 摘要

每個程序員都想寫出漂亮的代碼，但是什么是漂亮，這個我想每個人都有著自己的看法。那么我就說幾種典型的想法：

A. 寫出別人看不懂的代碼，讓別人覺得很高深。

B. 寫出簡短的代碼

C. 用最新的語言特性寫出代碼

這個我不發表評論，畢竟每個人有著自己的觀點，我也不能證明自己的就是對的。但是在這里，我想說一些典型的誤用。

2. 從dynamic談起

作為C#4.0的更新之一，dynamic已經越來越被推到了很多技術論壇的第一線。我看了很多關于dynamic的講解，但是我還是我一貫的觀點。既然我們用的微軟的東西，那么我們在使用一個語言特性的同時，我們首先要弄清微軟為什么要推出這門語言，不要盲目去使用。這樣往往會適得其反。

那下面我就看大多數教程中的一個傳統代碼：

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            dynamic p = new People("Test");
            Console.WriteLine(p.GetName());
        }
    }
    class People
    {
        private string name;
        public string GetName()
        {
            return name;
        }
        public People(string name)
        {
            this.name = name;
        }
    }
}

但是正如很多評論中的質疑的一樣，這樣的操作究竟有什么作用？（我并不是懷疑很多作者不懂這個，而是說這個會誤導很多人）于是很多人就會不明不白地去跟風，去亂用dynamic。

那么我們就在這里說清，究竟為何dynamic。

3. dynamic和var

在說這兩個關鍵字之前，我們要先搞清楚兩個概念。什么叫強類型語言，什么叫弱類型語言。

一句經典的話我想最能解釋他們的區別了：static typing when possible，dynamic typing when needed.

其實也就是說：靜態語言是在編譯時確定類型，而弱類型是在運行時確定類型。

一個簡單的例子就能看出他們的區別：

首先是使用var的情況：

接下來是dynamic:

4. 究竟為何dynamic

在國外某博客中，我記得有這樣一個說法，是說dynamic會顛覆傳統的C#編程方式，從前說世間萬物皆為對象，那么現在世間對象皆為dynamic。

class People
{
    private dynamic name;
    public People(dynamic name)
    {
        this.name = name;
    }
    public dynamic Introduce()
    {
        dynamic s = "Hello,I am" + name;
        return s;
    }
    public delegate dynamic Notify(dynamic argument);
}

不過，就我個人而言，并不認同這種說法，已經有很多《“深入剖析”dynamic》之類的文章了，我就不在多寫了。總之dynamic會對效率產生很大的影響。如果這樣濫用dynamic：

A. 對程序的效率有很大影響

B. Visual Studio 強大的智能感知功能被完全廢棄了。

既然這樣，那么我們為什么要使用dynamic，就我的理解而言：

A. 語言的互操作，比如去調用C++的一個Com組件，我們完全可以用dynamic取代反射略顯復雜的語法。

B. 我們都知道var只能用于變量，而無法用于屬性，而我們使用var的情況往往是因為我們不大容易確定某一個變量（或者屬性）的類型，同樣，很可能出現一個類的屬性或者方法返回類型不易確定返回類型的情況，這個時候，我們就可以用dynamic了。比如：

public dynamic GetAllGrilFriendsDetails()
{
    var gfDetails = from o in db.People
                  where o.name = this.name
                  select new
                  {
                      Name = o.firstName + o.lastName,
                      Age = o.age,
                      Address = o.address
                  };
    return gfDetails;
}

為什么我在方法內部去用 dynamic gfDetails，如果你討厭去看IL代碼細節，那么我們只看由于dynamic產生的反編譯C#代碼數量也許就能嚇到你了：

5. 從誤用繼續說開去

任何一種事物永遠都是雙面性的，同樣，任何一種新鮮事物的產生總是會有著他的利和他的弊。究竟是利還是弊，其本質原因不在于他本身，而在于他周圍的環境對他的使用是利大于弊，還是利小于弊。

任何一個C#新語言特性也是亦然。而他周圍的環境就是我們程序員。

我看到過太多太多的誤用，比如對泛型的誤用，對委托的誤用，對擴展方法的誤用。

在這里就再談談擴展方法的誤用。

6. 何時擴展方法

我在中提過Prototype的缺點，在這里我只說一點：能夠動態地添加屬性和方法固然是增加了靈活性。可是我們討論一種情況，100個人同時來開發一個Javascript的項目，很多沒經驗的人愛上了玩轉prototype，一個人往這個類里加一個方法，還面向對象么？

擴展方法也是一樣，100個開發者同時去開發一個項目，每個人都寫一個擴展方法，那么這個項目會亂成什么樣大家可想而知。

那么什么時候該用擴展方法，我個人認為只有三種情況：

A. 你獨立負責一個組件的編寫，而這個組件需要調用其他組件中的類，而你常常需要用到某個類中的某個他并為提供的“方法”。那么這個時候，你可以在你的組件內特殊放置一個類，用來容納你所需的擴展方法。

B. 一個團隊面對的一個已經封裝好的組件，但是某個方法是這個組件沒有提供的，重寫組件實在麻煩，那好吧。擴展方法。

C. 其實這個與第二點有些相似，當你面對的是.NET Framework中提供的類庫，那么沒辦法，只能擴展方法。

7. 總結

其實誤用的根本就在于知其然而不知其所以然，在這里，就說明情況，實在懶著浪費唇舌去抨擊那些不值得我一抨擊的培訓學校了。

珍愛生命，遠離培訓。這是我唯一的勸告。