1. 摘要

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

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

B. 寫出簡短的代碼

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

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

2. 從dynamic談起

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

那下面我就看大多數(shù)教程中的一個傳統(tǒng)代碼：

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;        }    }}

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

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

3. dynamic和var

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

一句經(jīng)典的話我想最能解釋他們的區(qū)別了：static typing when possible，dynamic typing when needed.

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

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

首先是使用var的情況：

接下來是dynamic:

4. 究竟為何dynamic

在國外某博客中，我記得有這樣一個說法，是說dynamic會顛覆傳統(tǒng)的C#編程方式，從前說世間萬物皆為對象，那么現(xiàn)在世間對象皆為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);}

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

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

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

既然這樣，那么我們?yōu)槭裁匆褂胐ynamic，就我的理解而言：

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

B. 我們都知道var只能用于變量，而無法用于屬性，而我們使用var的情況往往是因為我們不大容易確定某一個變量（或者屬性）的類型，同樣，很可能出現(xiàn)一個類的屬性或者方法返回類型不易確定返回類型的情況，這個時候，我們就可以用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;}

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

5. 從誤用繼續(xù)說開去

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

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

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

在這里就再談?wù)剶U展方法的誤用。

6. 何時擴展方法

我在中提過Prototype的缺點，在這里我只說一點：能夠動態(tài)地添加屬性和方法固然是增加了靈活性。可是我們討論一種情況，100個人同時來開發(fā)一個Javascript的項目，很多沒經(jīng)驗的人愛上了玩轉(zhuǎn)prototype，一個人往這個類里加一個方法，還面向?qū)ο竺矗?/span>

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

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

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

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

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

7. 總結(jié)

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

珍愛生命，遠離培訓(xùn)。這是我唯一的勸告。

 

NET技術(shù)：.NET,你忘記了么？（八）-- 從dynamic到特性誤用，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。