以下是轉載，轉載自：http://blog.csdn.net/lxwde/archive/2006/07/02/865523.aspx
本訪談系列的翻譯已經徵得原作者的同意，轉載請保留原作者和譯者的鏈接。
Copyright © 1996-2005 Artima Software, Inc. All rights reserved
Delegates, Components, and Simplexity
A Conversation with Anders Hejlsberg, Part III
by Bill Venners with Bruce Eckel
September 1, 2003
委託、組件以及表面上的簡單性
翻譯：劉曉偉
摘要
Anders Hejlsberg，C#的主架構師，與Bruce Eckel和Bill Venners談論了談論了委託（delegates）以及C#對於組件的概念給予的頭等待遇。
Anders Hejlsberg，微軟的一位傑出工程師，他領導了C#（發音是C Sharp）編程語言的設計團隊。Hejlsberg首次躍上軟件業界舞臺是源於他在80年代早期爲MS-DOS和CP/M寫的一個Pascal編譯器。不久一個叫做Borland的非常年輕的公司僱傭了他並且買下了他的編譯器，從那以後這個編譯器就作爲Turbo Pascal在市場上推廣。在Borland，Hejlsberg繼續開發Turbo Pacal並且在後來領導一個團隊設計Turbo Pascal的替代品：Delphi。1996年，在Borland工作13年以後，Hejlsberg加入了微軟，在那裏一開始作爲Visual J++和windows基礎類庫（WFC）的架構師。隨後，Hejlsberg擔任了C#的主要設計者和.NET框架創建過程中的一個主要參與者。現在，Anders Hejlsberg領導C#編程語言的後續開發。
2003年7月30號，Bruce Eckel（《Thinking in C++》以及《Thinking in Java》的作者）和Bill Venners（Artima.com的主編）與Anders Hejlsberg在他位於華盛頓州Redmond的微軟辦公室進行了一次面談。這次訪談的內容將分多次發佈在Artima.com以及Bruce Eckel將於今年秋天發佈的一張音頻光碟上。在這次訪談中，Anders Hejlsberg談論了C#語言和.NET框架設計上的一些取捨。
· 在 第一部分：C#的設計過程中， Hejlsberg談論了C#設計團隊所採用的流程，以及在語言設計中可用性研究（usability studies）和好的品味（good taste）相對而言的優點。
· 在第二部分:Checked Exceptions的問題中, Hejlsberg談論了已檢測異常（checked exceptions）的版本（versionability）問題和可伸縮性（scalability）問題。
· 在第三部分裏，Hejlsberg 談論了委託（delegates）以及C#對於組件的概念給予的頭等待遇。
簡單（Simplicity）vs.表面上的簡單（Simplexity）
Bill Venners: C#與Java的一個不同之處是它向感興趣的對象傳播事件的方式。Java使用實現了listener接口的類（通常是內部類）。C#使用委託（delegates），更有點像函數指針。爲什麼要選擇委託呢？
Anders Hejlsberg: 讓我先說說通常我是如何看待簡單性（simplicity）的。從來沒有人爭論說簡單不好，但是人們給簡單下的定義千差萬別。有一種簡單性（simplicity）我喜歡叫做“表面上的簡單（simplexity）”。當你試圖把一些極其複雜的東西包裹（wrap）到相對簡單的東西里的時候，通常你只是隱藏了（shroud）複雜性。實際上你並不是在設計一個真正簡單的系統。從某種意義上說你把它弄得更復雜了，因爲現在用戶必須弄明白你省略掉了哪些東西而說不定什麼時候他們又需要用上。這就是“表面上的簡單（simplexity）”。對我來說，簡單性必須是真正意義上的，也就是說你越往下探究它就越簡單。而不應該是你越深入探究它就越複雜。
委託（Delegates）vs.接口（ Interfaces）
Anders Hejlsberg: 委託添加了一種類和接口所沒有的表達方法，這也是爲什麼我認爲它們是重要的。走在我們前面的那些編程語言意識到了它們的重要性。它們有許多名稱：函數指針，成員函數指針。在LISP裏它們被叫作閉包（closures）。當歸結爲一點的時候，它們就是函數式編程（functional programming）的全部。它們非常有用。
Bill Venners: 怎麼有用呢？
Anders Hejlsberg: 實際上你可以用接口來做委託可以做的事情，但是你得做很多例行公事性質的事情。舉個例子，讓我們看看你在Java裏和.NET世界分別是如何處理事件的。因爲Java裏沒有委託，所以你最終選擇使用接口。
你定義一個接口用以代表你的所有事件。這個接口可以聲明一個、兩個、三個、四個方法，或者更多。好了，現在有一個問題。如何結構化它們並不十分清楚。你要爲自己所分發的（outgoing）事件準備多少個接口？你是要每個事件一個接口呢還是要所有事件都用一個接口？沒有人提供明確的指導，而且有時候它會在某些地方陷入中間狀態。現在，爲了處理由組件（component）所產生的事件，你必須實現這個接口。當然如果你想要處理來自不同組件的同一組（set）事件，你必須得實現這個接口兩次，而這是辦不到的。這種情況下你需要創建一個適配器（adapter）。這麼一來那些例行公事性質的事情就開始在你面前晃悠了。
使用內部類可以減少一些繁文縟節，但是儘管如此，使用接口還有一個問題就是事件的接受者必須知道他在接受事件。他必須顯式地實現listener接口。與此形成對比的是，使用委託只要簽名（signature）一致，你就可以把它們對接在一起（slot together）。處理事件的人不需要關心他是如何被調用的。這只不過是個方法（method）罷了。
Bruce Eckel: 有點弱類型化（weaker typing）的意思。
Anders Hejlsberg: 是的，實際上它就是。
Bruce Eckel: 也就是說它更靈活了。
Anders Hejlsberg: 是的，確實如此。它完全取決於你是否有一致的簽名（signature），也就是參數列表。如果你有一致的參數列表，你就可以把它們捆綁在一起。而且從概念上它完全符合最終用戶對於回調（call back）的期望，對嗎？給我一些參數，然後我（用它們）寫一些代碼。對我來說聽起來更像是一個方法。抱歉，我是想要給你一個關於那個方法的引用，這實際上就是委託。
Bruce Eckel: 而且最終你並沒有喪失類型檢測。類型檢測是在運行時刻做的，對嗎？
Anders Hejlsberg: 不，更多情況下是在編譯時刻。當構造一個delegate的時候，你會得到C++程序員可能稱之爲綁定的成員函數指針的東西。Delegate引用特定對象的一個方法。如果那個方法是虛函數，你可以準確地找出需要的是哪個函數。所以從某種意義上來說，在delegate被構造的時候就你可以確定是哪個虛函數。通過delegate所完成的調用從字面上看只不過就是一個間接的調用指令。
Bruce Eckel: 其它地方並不需要間接調用了。
Anders Hejlsberg: 你說的對，你可以在構造delegate的時候一勞永逸地解析出虛函數表（VTBL）的間接調用，以後每次通過delegate調用的時候就可以直接找到那個方法。所以說，委託不僅僅比接口分派（interface dispatch）效率更高，而且它們也可能比常規的方法分派（method dispatch）效率高。
Bruce Eckel: C#還有組播委託（multicast delegate），也就是說一個delegate可以觸發多個函數被調用。它是一個正交（orthogonal）特性嗎？
Anders Hejlsberg: 組播（Multicast）是一個完完全全的正交特性。說實話，我對組播是否是非常好的東西持中立的態度。我認爲確實有用得着它的地方，但是我也覺得我們應該保守一點認爲所有的delegates都是單播的（single cast）。有些人發現多播非常重要，而且它在一些地方工作的很好，但是絕大多數情況下委託都是單播的。實際上，我們把系統構建成了只有在你使用多播的時候才需要爲它付出一定的代價。
Bill Venners: 您剛纔說的簡單（simplicity）和表面上的簡單（simplexity）如何適用於委託呢？簡單性在哪裏？表面上的簡單又在哪裏？
Anders Hejlsberg: 如果你用接口來模擬委託，那你最終會陷入繁文縟節和一大堆適配器裏。實際上，看看任何捆綁JavaBeans的工具就知道了。它們產生一大堆適配器然後告訴你，“不要改動下面這寫代碼。我們會爲你產生這些古怪的輔助類。”我認爲，這就是表面上的簡單。整個系統不是真正意義上的簡單，實際上非常複雜，但是如果你只是瞄一眼的話看起來是很簡單。
組件是頭等的概念（Components are First-Class）
Bill Venners: 在公佈在O’Reilly網絡上的一篇訪談中，爲了說明C#對於屬性（properties）和事件（events）的支持是合理的，你說道，“現今開發者都在構建軟件組件（components），而不是自成一體的應用程序或者類庫。每個人都是在構建新組件，而新組建繼承自由宿主環境所提供的某些基礎組件。這些組件覆寫（override）某些方法和屬性，處理一些事件，然後再把組件放回去。把這些概念當作first classs是很重要的。”
我希望能更好地理解你這段話的意思，因爲我一直認爲自己是在構建類，而不是組件。你指的是爲了讓其他人以Delphi、Visual Basic或者JavaBeans的方式連接到一起而構建組件的人們？你說的組件是這個意思嗎？
Anders Hejlsberg: 組件（component）這個詞最大的好處就是你可以拿它來到處忽悠，而且它聽上去也很棒，但是我們所思考的並不是同一個東西。最簡單的形式，提到組件的時候我的意思是一個類再加一些東西。組件是一個自包含的（self-contained）軟件單元，不僅僅是代碼和數據。它是一個通過屬性（properties）、方法和事件來暴露自己的類。它是一個有額外attributes與它關聯的類，這些attributes的形式是元數據（metadata）或者naming patterns或者隨便其它什麼形式。這些attributes提供一些動態的額外信息，諸如組件是如何嵌入一個特定的宿主環境、它如何讓自己持久化——所有你想通過元數據進行說明的額外的東西。通過元數據，IDE可以智能地推斷出某個組件是幹什麼的然後顯示給你關於它的文檔。組件把所有這些都整合起來。
Bill Venners: 當使用Java的時候，我覺得是我是在設計類庫，而不是組件庫，可能是因爲get和set太不優雅了。我確實使用了get和set，而且我的確也觸發事件（fire events），但是我原本並沒有打算讓這些類在一個Bean構建器的IDE裏使用。我想象中它們應該被那些手寫代碼的人使用。所以我仍然懷疑有多少人在實際上寫類似於JavaBean的組件以及這是否是大勢所趨，因爲依我自己的經驗我並沒有見到很多。
Anders Hejlsberg: 現今主流的面向對象編程語言都是混血兒。它們有許多結構化的編程方法在裏面。對象在很大程度上還是添加了一大堆方法和一個this指針的結構（structs）。我想，從概念上來說，當你想到一個對象或者一個組件的時候，它們絕對應該有屬性也絕對應該有事件。給編程語言裏的這些東西頭等待遇可以讓一切更簡單。
人們可能會爭論說C#對於屬性和事件的支持只不過是語法糖衣（syntactic sugar）罷了，但是所有的東西不都是語法糖衣嗎？對嗎？對象也只是語法糖衣。我們可以自己弄一個虛函數表（VTBL），用C裏面的宏（macros）就可以了，不是嗎？毫無疑問，你可以用C寫出面向對象的程序。只不過是非常複雜罷了。類似地，你可以用C++或者Java寫組件，但是因爲核心概念（core concepts）在這兩種語言裏沒有作爲第一等（first class）的東西，所以你最終還是得藉助於別的東西。這裏又說到了這個詞（指first class）。就properties來說，它們並不是真正意義上的properties，它們是getBla和setBla。但是當它們在屬性檢視器裏顯示出來的時候，它們是bla。你只需要知道那裏有一個映射（mapping）就可以了。
很明顯，組件是一種趨勢。我們就是以這種方式使用類的，但是在大多數我們與組件打交道的語言裏，它們並沒有作爲頭等的概念。我只是想說它們應該成爲頭等的概念。
我們談論PME編程模型——屬性（properties）、方法（Methods），事件（events）——已經有很長一段時間了，而且我們在日常編程中都使用過它們。爲什麼我們不實實在在地在編程語言裏給它們頭等的待遇呢？
下週
Anders Hejlsberg訪談的下一部分將會在（2003年）9月15號，星期一貼出來。如果你想收到Artima.com上新文章每週簡報的電子郵件，請訂閱Artima Newsletter。
反饋
對本文所描述的設計原則有自己的觀點麼？那麼請到News&Ideas論壇討論這篇文章Delegates, Components, and Simplexity。
資源
深入C#：微軟主架構師Anders Hejlsberg訪談：
http://windows.oreilly.com/news/hejlsberg_0800.html
A Comparative Overview of C#:
http://genamics.com/developer/csharp_comparative.htm
Microsoft Visual C#:
http://msdn.microsoft.com/vcsharp/
Anders Hejlsberg不是Artima的採訪對象中第一個提到品味的。Jim Waldo在他的訪談中針對構建一個由有品味的程序員組成的團隊給出了幾乎同樣的評述：
http://www.artima.com/intv/waldo10.html
Ken Arnold’s的訪談有一整部分都是關於設計品味的——品味和美學（Taste and Aesthetics）：
http://www.artima.com/intv/taste.html