引言

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

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

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

簡(jiǎn)單說來，IoC是“誰制定規(guī)范，誰就擁有控制權(quán)；誰執(zhí)行規(guī)范，誰就被控制”。如果規(guī)范借助于C#的靜態(tài)類型檢查，比如接口或抽象類，那么規(guī)范就表現(xiàn)出較強(qiáng)的語法約束性，使得組件A的編寫比較獨(dú)立，而組件B則受制與組件A。

本系列的第一篇舉了一個(gè)基于接口的IoC例子，我們看到當(dāng)需要采用第三方組件時(shí)，為了適用接口的靜態(tài)類型約束，不得不增加一個(gè)adapter去實(shí)現(xiàn)接口并包裝對(duì)第三方組件的調(diào)用。這表現(xiàn)出基于接口的IoC在粘合規(guī)范與實(shí)現(xiàn)時(shí)不太靈活。

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

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

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

Duck Typing

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

static void Main(string[] args) 
{
    object person= new Person(); 
    IPerson duck= Duck.Create(person);//創(chuàng)建鴨子對(duì)象
    Console.WriteLine(duck.Name + " will be " + (duck.Age + 1) + "next year");
    duck.Play("basketball");
    Console.WriteLine(duck.Mother);//為null
    //duck無法調(diào)用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對(duì)象沒有實(shí)現(xiàn)IPerson接口，我們一樣可以通過Duck.Create(person)創(chuàng)建鴨子對(duì)象調(diào)用person的屬性和方法。這種把接口和對(duì)象粘合的方式與委托和方法的粘合方式非常接近，真正達(dá)到了我們所謂把委托思想應(yīng)用于對(duì)象的想法。

C#中要實(shí)現(xiàn)Duck.Create的功能，可以通過Emit動(dòng)態(tài)創(chuàng)建實(shí)現(xiàn)T接口的代理類，在代理類中攔截方法調(diào)用，并將方法調(diào)用轉(zhuǎn)換成target對(duì)象上的反射調(diào)用。Castle開源項(xiàng)目的DynamicProxy是一個(gè)很好用的工具，在它的幫助下很容易實(shí)現(xiàn)代理類的創(chuàng)建和方法調(diào)用的攔截。

動(dòng)態(tài)類型

事實(shí)上，duck typing是動(dòng)態(tài)類型概念的一種。C#4.0已經(jīng)通過dynamic關(guān)鍵字來實(shí)現(xiàn)動(dòng)態(tài)類型，讓我們先來看看下面的示例：

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關(guān)鍵字，我們不需要在編譯時(shí)為person對(duì)象指定類型，編譯器不會(huì)進(jìn)行類型檢查，而是將對(duì)象的屬性訪問和方法調(diào)用轉(zhuǎn)換為反射調(diào)用，所以，只要對(duì)象的運(yùn)行時(shí)類型能通過反射找到匹配的屬性或方法即可。

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

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

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");//不存在的方法，可以通過編譯，但會(huì)拋出運(yùn)行時(shí)異常

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

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");

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

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

【編輯推薦】

1. C#實(shí)用基礎(chǔ)教程
2. 詳解C# 4.0中必選參數(shù)與可選參數(shù)混合的問題
3. 淺析C#3.0編碼習(xí)慣與命名規(guī)則