1. 摘要

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

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

B. 寫出簡短的代碼

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

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

2. 從dynamic談起

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

那下面我就看大多數(shù)教程中的一個(gè)傳統(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;        }    }}

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

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

3. dynamic和var

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

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

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

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

首先是使用var的情況：

接下來是dynamic:

4. 究竟為何dynamic

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

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

A. 對(duì)程序的效率有很大影響

B. Visual Studio 強(qiáng)大的智能感知功能被完全廢棄了。

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

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

B. 我們都知道var只能用于變量，而無法用于屬性，而我們使用var的情況往往是因?yàn)槲覀儾淮笕菀状_定某一個(gè)變量（或者屬性）的類型，同樣，很可能出現(xiàn)一個(gè)類的屬性或者方法返回類型不易確定返回類型的情況，這個(gè)時(shí)候，我們就可以用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代碼細(xì)節(jié)，那么我們只看由于dynamic產(chǎn)生的反編譯C#代碼數(shù)量也許就能嚇到你了：

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

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

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

我看到過太多太多的誤用，比如對(duì)泛型的誤用，對(duì)委托的誤用，對(duì)擴(kuò)展方法的誤用。

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

6. 何時(shí)擴(kuò)展方法

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

擴(kuò)展方法也是一樣，100個(gè)開發(fā)者同時(shí)去開發(fā)一個(gè)項(xiàng)目，每個(gè)人都寫一個(gè)擴(kuò)展方法，那么這個(gè)項(xiàng)目會(huì)亂成什么樣大家可想而知。

那么什么時(shí)候該用擴(kuò)展方法，我個(gè)人認(rèn)為只有三種情況：

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

B. 一個(gè)團(tuán)隊(duì)面對(duì)的一個(gè)已經(jīng)封裝好的組件，但是某個(gè)方法是這個(gè)組件沒有提供的，重寫組件實(shí)在麻煩，那好吧。擴(kuò)展方法。

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

7. 總結(jié)

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

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

 

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

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