昨天在和一位朋友討論到委托與接口的問題,一開始我覺得很不可思議,這兩個東西的概念怎么會混淆呢?要混淆也是接口和抽象類,委托和事件相混淆啊!但是著我的一個例子我馬上意識到很有可能因為我將要表現的這個例子,讓很多朋友混淆了委托與接口的用途.所以我想通過這篇文章試圖說明白委托和接口的概念和用途,其實他們倆的差別還是很大的.

本文適合對委托和接口概念或用途不了解的朋友.

本文適合對委托和接口概念非常了解的朋友,并且歡迎各位朋友與Snake一起探討有關這方面的知識. 本文不適合對委托和接口概念或用途了解一知半解(模糊)的朋友,這篇文章可能會對您產生誤導,請千萬別看. (本文原文是一篇沒有好好排版過的email,我這里將會部分摘抄,部分改進,如果有什么地方您覺得莫名其妙,我將非常感謝您的指正!)

在文章正式開始之前我需要將MSDN上對委托和接口的內容放上來,作為文章之基.

委托:

委托是一種定義方法簽名的類型。當實例化委托時，您可以將其實例與任何具有兼容簽名的方法相關聯。您可以通過委托實例調用方法。

委托用于將方法作為參數傳遞給其他方法。事件處理程序就是通過委托調用的方法。您可以創建一個自定義方法，當發生特定事件時某個類（例如 Windows 控件）就可以調用您的方法.

委托具有以下特點：

委托類似于 C++ 函數指針，但它們是類型安全的。

委托允許將方法作為參數進行傳遞。

?

委托可用于定義回調方法。

?

委托可以鏈接在一起；例如，可以對一個事件調用多個方法。

?

方法不必與委托簽名完全匹配。有關更多信息，請參見在委托中使用變體（C# 和 Visual Basic）。

?

C# 2.0 版引入了匿名方法的概念，此類方法允許將代碼塊作為參數傳遞，以代替單獨定義的方法。C# 3.0 引入了 Lambda 表達式，利用它們可以更簡練地編寫內聯代碼塊。匿名方法和 Lambda 表達式（在某些上下文中）都可編譯為委托類型。這些功能統稱為匿名函數。有關 Lambda 表達式的更多信息，請參見Anonymous Functions (C# Programming Guide)。

?

接口:

?

接口描述的是可屬于任何類或結構的一組相關功能。接口可由方法、屬性、事件、索引器或這四種成員類型的任意組合構成。接口不能包含字段。接口成員一定是公共的。

?

當類或結構繼承接口時，意味著該類或結構為該接口定義的所有成員提供實現。接口本身不提供類或結構能夠以繼承基類功能的方式繼承的任何功能。但是，如果基類實現接口，派生類將繼承該實現。

類和結構可以按照類繼承基類或結構的類似方式繼承接口，但有兩個例外：

類或結構可繼承多個接口。

類或結構繼承接口時，僅繼承方法名稱和簽名，因為接口本身不包含實現。

?

接口具有下列屬性：

?

接口類似于抽象基類：繼承接口的任何非抽象類型都必須實現接口的所有成員。

不能直接實例化接口。

?

接口可以包含事件、索引器、方法和屬性。

?

接口不包含方法的實現。

?

類和結構可從多個接口繼承。

?

接口自身可從多個接口繼承。

?

正文開始

?

在寫這些文字的時候我又將以上的各個概念熟悉了一遍,以防自己把自己忽悠混淆了.所以不適合群眾請盡快退散.另外如果您看完上面的定義和特征后就從兩者的混淆中走了出來,您也可以嘗試繼續往下看.

?

首先,關于委托的用法,我們可以這樣使用:

public?int?Calculate(Func<int,?int,?int>?del) ?{ ?????int?a?=?1,?b?=?2; ????return?del(a,?b); ??}?

我們可以通過傳不同的Func來改變整個方法的結果.

public?int?Add(int?a,?int?b) ?{?return?a?+?b;?} ??public?int?Sub(int?a,?int?b) ??{?return?a?-?b;?} ??//調用方法如下 ?public?void?TestMethod() ?{ ??????int?result?=?Calculate(Add);//the?result?is?3 ?int?anotherResult?=?Calculate(Sub);//the?result?is?-1 ??}?

首先我在Calculate方法中已經確定了2個數的值,并且包括在該方法當中.在輸出結果的時候能明顯看出傳遞的委托不同,其結果也不同.我們使用委托來改變方法的執行內容,我們不但可以改變其方法的內容,也可以在執行該方法的時候順便做點什么(比如說做個日志記錄).

噢,可能您覺得二者容易混淆的地方在于..我還是舉個例子比較好解釋. : )

public?interface?ICal ?{ ?int?Calculate(int?a,?int?b); ??} ?//有多個類實現了ICal接口. ?public?class?Add?:?ICal ??{ ???public?int?Calculate(int?a,?int?b) ???{?return?a?+?b;?} ??} ?public?class?Sub?:?ICal ??{ ??public?int?Calculate(int?a,?int?b) ?????{?return?a?-?b;?} ??} ?//然后通過調用不同類來獲取不同的方法 ??public?static?void?Main() ??{ ????ICal?cal?=?new?Add(); ?????//ICal=new?Sub(); ?????Console.Write(cal.Calculate(1,?2)); ?}?

講解一下,通過上面的例子我們可以知道在創建一個具有計算功能(Calculate)的接口ICal之后,產生了兩個具有計算功能的具體類,分別是Add和Sub.為了要獲得結果,我們創建了一個需要有計算功能的”坑”,并賦予能與此”坑”相匹配的類Add(或Sub),最后從該坑中調用Calculate的結果就行.

貌似說的過去?好,那么我至少要讓你覺得有個適用范圍吧!看下面的例子.

比如有個Person類的數組arr.這時候我們可以通過委托的方法實現arr的排序.可是系統怎么知道2個Person哪個排在前面,哪個該排在后面?這時候我們就可以傳進一個委托來告訴系統Peron類的大小.

arr.Sort(p?=> ?{ ??????p.ID ??});?

該lambda表達式意思是丟給該Sort方法一個排序的Key(此key能夠進行大小比較),那么Sort就可以根據此key來進行比較.那通過接口呢?首先得創建一個繼承自IComparer<Person>的類,我就拿本身繼承它吧.

好吧,它本來是很麻煩的:

private?int?SortDelegate(Person?p) ?{ ???return?p.ID; ?} ??public?void?TestMethod() ??{ ?arr.Sort(new?Func<Person,?int>(SortDelegate)); ??}?

但是我們要承認C# 3.0帶給我們的便利.

現在,我們要讓Person類實現接口的規定.

public?int?Compare(Person?x,?Person?y) ??{ ??//假設person的ID是int類型 ?return?x.ID?-?y.ID; ?}?

那么我們的實現方法就可能是這樣:

arr.Sort((new?Person()?as?IComparer<Peron>)?comp);?

不能再繼續舉例子了,我承認我忽悠您了.這些看上去都可以的實現方法有本質的區別!

首先我們看第一個委托例子:在Calculate時我們的委托被允許使用了該方法內的兩個變量a,b從而改變了整個方法的結果.在整個過程中委托時很被動的,因為它不知道自己會在什么時候被觸發.上面的例子很簡單,使您沒有這種感覺,而且前面說過在方法執行的時候當委托被觸發我們可以干點別的,比如說做個日志記錄什么的,此時接口有能力又不破壞方法本身運行結構,又能做日志記錄嗎?顯然實現了接口的類只能重寫一遍該方法.

路人甲:那我在接口的實現中再調用一下原方法,最后在方法的前面或后面加入日志記錄功能不就完了嗎?

Snake:殺雞焉用宰牛刀?且不說再原方法的可行性,就算可行了,麻煩不說,萬一這個方法執行有多個階段,每個階段都要日志記錄呢?委托能深入方法,并且由方法控制它安放之地,讓委托能起到關鍵作用,此時作為接口大哥的牛刀也剔不干凈雞骨上的肉喲~.

其次說接口的優點.我們前面可以看到委托能深入方法,也就是說委托的關注群體是方法們,而接口關注的群體則是類們.接口讓類必須實現相同簽名的方法或屬性,以便在程序中通過調用可變的方法.既然是因為類的關系,那么它的方法肯定是不可變的了,每個實現了該接口的類,即便功能差不多也要完完全全寫一遍,但是類的地盤大,肚子里的墨水多,雖然在Add類中通過ICal可調用的方法也就一個Calculate(),但是在Calculate始終是Add類的子民,所以該Calculate方法可以調用Add類中所有能調用的資源.而如果是Sub類的話,它的子民Caculate可調用的資源又與Add類不盡相同,畢竟同是Calculate,國籍不同,文化和生活方式也不同嘛,哈哈.

而接口的能力卻是委托所不能企及的地方.它只能被方法藏在伸出,方法外一片藍天而它卻無能為力.如果讓類比作一個國家,方法比作一個人,那么委托不就是深藏在人大腦內的處理方式的思維嗎?不同的人,思維可以變,當鄉下人看到城市中的高樓大廈不禁感嘆,可鄉下人在城市中生活習慣之后,高樓大廈又能怎樣,他早已習以為常.

最后的論點有點晦澀,前面的例子具有誤導性,所以本篇文章需要讀懂個人認為不是很容易,畢竟個人對于表達能力還是比較不自信的.希望各位同仁海涵.

如果各位覺得本文污染了園子的首頁,您可以毫不客氣的點反對,如果您覺得還不錯的話,我建議您可以考慮點擊下推薦.

原文標題：寫給會混淆委托和接口概念和用途的朋友們

鏈接：http://www.cnblogs.com/micone/archive/2010/08/02/1790680.html

本文轉自左正博客園博客，原文鏈接：http://www.cnblogs.com/soundcode/archive/2010/12/27/1917878.html，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的详解.NET中容易混淆的委托与接口的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。