引言

C#是靜態類型語言，要使用類型必須引用該類型的定義。因此，從軟件組織角度會發生組件間的引用依賴關系。常見的引用依賴關系有兩種模式：

a. 正向依賴：組件A用到了組件B中定義的類T，組件A直接引用組件B，依賴關系是“組件A -> 組件B”。

b. 反向依賴：組件A通過接口I定義功能規范，針對抽象編程；組件B反過來引用組件A，并定義類T實現接口I；由另一組件C將I與T粘合起來，依賴關系是“組件A <- 組件B”。這就是著名的IoC方式。

簡單說來，IoC是“誰制定規范，誰就擁有控制權；誰執行規范，誰就被控制”。如果規范借助于C#的靜態類型檢查，比如接口或抽象類，那么規范就表現出較強的語法約束性，使得組件A的編寫比較獨立，而組件B則受制與組件A。

本系列的第一篇舉了一個基于接口的IoC例子，我們看到當需要采用第三方組件時，為了適用接口的靜態類型約束，不得不增加一個adapter去實現接口并包裝對第三方組件的調用。這表現出基于接口的IoC在粘合規范與實現時不太靈活。

但是，規范和類型約束沒有必然的聯系。在基于委托的IoC例子中，我們不需要任何的adapter，就能輕松的粘合規范與實現，表現出較強的靈活性。這就是通過委托定義規范，不會造成組件B對組件A的依賴，組件A和組件B的實現都顯得比較獨立。

實際上，我們還可以有比委托更靈活的規范表達方式，比如：通過HTTP + XML來表達規范，這樣甚至是語言無關的，完全可能組件A由C#編寫，組件B由Java編寫。

上面列舉的3種規范定義方式：基于接口、基于委托、基于HTTP + XML分別代表了由約束到協議，由嚴格到靈活的3種風格。當然，還有更多的方式，但這里只列舉這三種作為代表。動與靜之間需要把握一個分寸，接口過于死板；而HTTP + XML的方式則完全是基于運行時協議的，需要自己做很多檢查工作；委托的好處在于既消除了組件A、B的依賴關系，又能享受IDE智能提示和編譯器檢查（簽名檢查）等好處。因此，委托是把動與靜結合得恰到好處的中庸之道。

Duck Typing

但可惜委托還無法覆蓋接口或類的所有功能，有朋友提到“接口是對象功能的抽象，而委托是方法功能的抽象”就是這個意思。那么我們自然會想，有沒有一種方式，能將委托的思想應用于對象呢？有！它就是：duck typing。前文已經談到，duck typing關注“對象能做什么”或者說“如何使用對象”，對象繼承自什么類，或者實現什么接口并不重要。duck typing的本意為“如果一只動物，走起來像鴨子，叫起來像鴨子，我就可以把它當作鴨子”。與繼承性多態相對應，duck typing可以實現非繼承多態。按duck typing的本意，純正的duck typing看起來應該是這個樣子：

static void Main(string[] args) 
{
    object person= new Person(); 
    IPerson duck= Duck.Create(person);//創建鴨子對象
    Console.WriteLine(duck.Name + " will be " + (duck.Age + 1) + "next year");
    duck.Play("basketball");
    Console.WriteLine(duck.Mother);//為null
    //duck無法調用duck.Sing() 
}
interface IPerson
{
    string Name { get; }
    int Age { get; }
    string Mother { get; }
    void Play(string ball);
}

class Person
{
    public string Name { get { return "Todd"; } }
    public int Age { get { return 26; } }
    public void Play(string ball) { Console.WriteLine("Play " + ball); }
    public void Sing(string song) { Console.WriteLine("Sing " + song");} 
} 

上面的例子中，雖然person對象沒有實現IPerson接口，我們一樣可以通過Duck.Create(person)創建鴨子對象調用person的屬性和方法。這種把接口和對象粘合的方式與委托和方法的粘合方式非常接近，真正達到了我們所謂把委托思想應用于對象的想法。

C#中要實現Duck.Create的功能，可以通過Emit動態創建實現T接口的代理類，在代理類中攔截方法調用，并將方法調用轉換成target對象上的反射調用。Castle開源項目的DynamicProxy是一個很好用的工具，在它的幫助下很容易實現代理類的創建和方法調用的攔截。

動態類型

事實上，duck typing是動態類型概念的一種。C#4.0已經通過dynamic關鍵字來實現動態類型，讓我們先來看看下面的示例：

string json = @"{ ""FirstName"": ""John"", ""LastName"": ""Smith"", ""Age"": 21 }"; 
dynamic person = CreateFromJson(json);
Console.WriteLine("{0} will be {1} next year", person.FirstName, person.Age + 1);
Console.WriteLine(person.ToJson());
person.Play("basketball");
string firstName = person.FirstName;
int age = person.Age;
Func toJson = person.ToJson>;
Action play = person.Play>;

通過dynamic關鍵字，我們不需要在編譯時為person對象指定類型，編譯器不會進行類型檢查，而是將對象的屬性訪問和方法調用轉換為反射調用，所以，只要對象的運行時類型能通過反射找到匹配的屬性或方法即可。

上面的例子通過json創建了一個dynamic對象，就像javascript中操作json一樣方便。在運行 時，person.FirstName和person.Age能通過反射正確地進行屬性訪問，person.ToJson()也可以正確地執行，但 person.Play( "basketball")由于運行時類型不存在該方法而拋出異常。

C#4.0的味道如何？很爽嗎？不過，說實在的，我覺得有點兒不太舒服了！仔細想想，它像接口，像委托，還是更像HTTP + XML? 對于dynamic對象，編譯器不進行對象類型檢查，不進行屬性類型檢查，也不進行方法簽名檢查。很明顯，它像HTTP+XML，完全基于運行時協議，沒有一點兒靜態的東西。如果類比委托的話，更理想的方式應該是，不進行對象類型檢查，但進行屬性類型和方法簽名檢查，就像下面這樣：

string json = @"{ ""FirstName"": ""John"", ""LastName"": ""Smith"", ""Age"": 21 }";
dynamic person = CreateFromJson(json);
Console.WriteLine("{0} will be {1} next year", person.FirstName, person.Age + 1);
Console.WriteLine(person.ToJson());
person.Play("basketball");//不存在的方法，可以通過編譯，但會拋出運行時異常

這樣，除了屬性和方法的名稱是動態的外，屬性的類型和方法的簽名都是靜態的，把運行時錯誤的可能降到最低，同時享受靜態檢查的好處。其實，沿著這個思路，我們大可不必等著C#4.0的dynamic才開始動態類型，在C#2.0時代也可以這樣：

object jsonObj = CreateFromJson(@"{ ""FirstName"": ""John"", 

""LastName"": ""Smith"", ""Age"": 21 }");
Dynamic person = new Dynamic(jsonObject);
string firstName = person.Property("FirstName");
int age = person.Age("Age");
Func toJson = person.Method>("ToJson");
Action play = person.Method>("Play");

看到這里，相信您一定明白該如何實現Dynamic類了吧？如果覺得有用，就自己嘗試實現一下吧！

博文鏈接：http://www.cnblogs.com/weidagang2046/archive/2009/03/26/1421943.html

【編輯推薦】

1. C#實用基礎教程
2. 詳解C# 4.0中必選參數與可選參數混合的問題
3. 淺析C#3.0編碼習慣與命名規則