（轉）Anders Hejlsberg談C#設計過程
博客分類： 程序開發
C++CC#設計模式編程
原文：http://msdn.microsoft.com/vcsharp/headlines/hejlsberg/default.aspx
Anders Hejlsberg為Borland工作13個春秋后，于1996年加盟微軟，最初參與設計Visual J++和WFC(Windows Foundation Classes)。然后，擔任C#首席設計師和Microsoft .NET Framework設計小組核心成員。目前，他還將繼續領導C#語言后續版本的設計工作。
2003年7月30日，Hejlsberg在他微軟的辦公室會見了Bruce Eckel(《Thinking in C++》和《Thinking in Java》的作者)、Bill Venners(Artima.com主編)。談話內容主要分為三個部分：
一、C#設計過程；語言可用性研究和語言美學。
二、Checked Exceptions特征的版本相關性和擴展性。
三、委托的概念；組件概念在C#中的至高地位。
一
1、C#設計過程
Bruce Eckel：我聽說C#是一個工程師小組在一個屋子里設計出來的？
Anders Hejlsberg：是的。4年來，我們一直呆在這個屋子里。現在，每周一、三、五，我們仍然在這里會面。
Bruce Eckel：我很想了解一些關于C#設計過程的情況。我直接或間接參與過幾種語言的設計工作，如Python。在Python設計過程中，Guido van Rossum被我們戲稱為“仁慈的獨裁者”。
Anders Hejlsberg：哦，Guido van Rossum就相當于我的位置。
Bruce Eckel：那么你是C#小組“仁慈的獨裁者”么？
Anders Hejlsberg：我一般扮演最后拍板者的角色。比如，我們被一個問題困擾多時，到了非解決不可、只能作不二選擇的時候，是由我來作最后決定的。當然大多數這樣的情況下，正確的選擇是顯而易見的。
Bruce Eckel：C#的設計過程是不是和Turbo Pascal、Delphi十分相似？
Anders Hejlsberg：后面兩者的設計過程不是那么規范的。因為Turbo Pascal主要由我一個人設計，而Delphi也是我和Chuck Jazdzewski、Gary Whizin等幾個為數不多的人來完成，所以沒有必要引入非常規范的設計過程。相反的，C#的設計過程則十分規范，每周一、三、五從1：00到3：00, 我們都會召開一個正式會議，會議議程也相當靈活，所有的問題都會拿到桌面上公開討論、仔細推敲。我們還在互聯網上建立了一個Wiki，這些問題及其解決方案，以及其他一些相關的東西都被發布在上面。
Bruce Eckel：那你們是如何發現這些的問題呢？
Anders Hejlsberg：呵呵，我們有一套行之有效的方法。我們可以通過很多途徑來得到用戶對語言設計的反饋意見——如軟件設計咨詢會、網絡新聞組。這些反饋意見包括：疑問、軟件Bugs、不一致、不規范問題等。這樣我們就能有的放矢了。最后我們將這些問題整理成表，并一一重現它們。對于每個問題，我們都會認真對待，詢問自己：“我們對這個問題有新的想法嗎？真的沒有嗎？這個問題已經擱置好幾個星期了，我們立即花30分鐘集中精力研究一下，看這次是否能有所斬獲。”
Bruce Eckel：那可能一個問題長期沒有解決，都臭不可聞了……
Anders Hejlsberg：也許有些臭問題只有放到下一個版本才能解決了。但是我認為這樣一個過程可以保證不會遺漏任何問題，因為它們都被登記在冊。有時候，你面對這些問題呆坐了很長時間，可能也沒什么結果。但問題畢竟是被我們逮住了，總有一天會再去“拜訪”它的。也可能不會再去“拜訪”了，但問題終歸是不會被弄丟的。
Bill Venners：C#設計小組包含哪些成員，他們都擔當什么角色？
Anders Hejlsberg：參與最初的C#設計的有Scott Wiltamuth、Peter Golde、Peter Sollich、Eric Gunnerson和我。C#2.0設計小組包括：Peter Hallam、Shon Katzenberger、Todd Proebsting，以及我自己。微軟研究院的Don Syme和Andrew Kennedy承擔了大部分一般性研究工作。
2、語言可用性研究和語言美學
Bill Venners：在C#的設計中，可用性研究、市場策略和語言美學的側重是如何權衡的？
Anders Hejlsberg：一般而言，好的語言設計過程體現了對設計小組成員的美學品味取向的綜合，也就是你剛才所說的語言美學觀。美學品味帶有極大的主觀性，很難定論，只有產品出來后，你才能仔細體味它。我認為任何程度的可用性研究都不能取代語言美學的價值，因為可用性研究是極有針對性、非常具體的。可能有人問你：“你認為這部分功能如何？”這個問題很難回答。“你對這個語言有什么看法？”你從何談起呢？你怎么可能花兩個小時就解決掉所有可用性問題？絕無可能。
Bruce Eckel：人們必須深入理解這個問題。
Anders Hejlsberg：使用一種編程語言會經歷一個感覺微妙變化的過程。只有使用幾個月之后用戶才能真正喜歡上它。他們會逐漸發現：“哦，它給人的感覺很舒服嘛。”你不能急于求成。
開始說過，我們在可用性研究上也做了大量工作，但主要是針對特定的功能。
Bill Venners：可以舉個例子么？
Anders Hejlsberg：我們將可用性研究的重點放在了IDE功能實現上。我們會問自己：“用戶是否知道在這里點擊右鍵會有什么結果？”在純語言功能部分，我們也考慮了一些可用性問題——例如在一些屬性和事件上——不過沒什么必要，真的。
我想在可用性研究上，語言特性不可能帶來和IDE特性一樣高的收益。你可以看到用戶點擊一個菜單項立即得到正確的反饋信息。而對語言來說，問題要復雜一些。例如：“它的概念容易理解么？”我們通過用戶咨詢會、留言板，比較好的解決了這些問題。用戶需要有個說話的地方，“對于這個新特性，我有這樣一些想法，你們是如何考慮的呢？”這樣的問題提得越多、尖銳越好，因為你肯定是最希望在產品出來以前就能知道用戶的想法，而不是產品推出以后。在一個語言特性被完全敲定前，我們通常都會考慮用戶的建議和意見的。
二
1、對Checked Exceptions特性持保留態度
（譯者注：在寫一段程序時，如果沒有用try-catch捕捉異常或者顯式的拋出異常，而希望程序自動拋出，一些語言的編譯器不會允許編譯通過，如Java就是這樣。這就是Checked Exceptions最基本的意思。該特性的目的是保證程序的安全性和健壯性。Zee&Snakey(MVP)對此有一段很形象的話，可以參見：
http：//www.blogcn.com/user2/zee/main.asp。
Bruce Eckel 也有相關的一篇文章（《Does Java need Checked Exceptions》），參見：
http：//www.mindview.net/Etc/Discussions/CheckedExceptions）
Bruce Eckel：C#沒有Checked Exceptions，你是怎么決定是否在C#中放置這種特性的么？
Anders Hejlsberg：我發現Checked Exceptions在兩個方面有比較大的問題：擴展性和版本控制。我知道你也寫了一些關于Checked Exceptions的東西，并且傾向于我們對這個問題的看法。
Bruce Eckel：我一直認為Checked Exceptions是非常重要的。
Anders Hejlsberg：是的，老實說，它看起來的確相當重要，這個觀點并沒有錯。我也十分贊許Checked Exceptions特性的美妙。但它某些方面的實現會帶來一些問題。例如，從Java中Checked Exceptions的實現途徑來看，我認為它在解決一系列既有問題的同時，付出了帶來一系列新問題的代價。這樣一來，我就搞不清楚Checked Exceptions特性是否可以真的讓我們的生活變得更美妙一些。對此你或許有不同看法。
Bruce Eckel：C#設計小組對Checked Exceptions特性是否有過大量的爭論？
Anders Hejlsberg：不，在這個問題上，我們有著廣泛的共識。C#目前在Checked Exceptions上是保持緘默的。一旦有公認的更好的解決方案，我們會重新考慮，并在適當的地方采用的。我有一個人生信條，那就是——如果你對該問題不具有發言權，也沒辦法推進其解決進程，那么最好保持沉默和中立，而不應該擺出一個非此即彼的架勢。
假設你讓一個新手去編一個日歷控件，他們通常會這樣想：“哦，我會寫出世界上最好的日歷控件！我要讓它有各種各樣的日歷外觀。它有顯示部分，有這個，有那個……”他們將所有這些構想都放到控件中去，然后花兩天時間寫了一個很蹩腳的日歷程序。他們想：“在程序的下一個版本中，我將實現更多更好的功能。”
但是，一旦他們開始考慮如何將腦海中那么多抽象的念頭具體實現出來時，就會發現他們原來的設計是完全錯誤的。現在，他們正蹲在一個角落里痛苦萬狀呢，他們發現必須將原來的設計全盤拋棄。這種情況我不是看到一次兩次了。我是一個最低綱領主義者。對于影響全局的問題，在沒有實際解決方案前，千萬不要將它帶入到整個框架中去，否則你將不知道這個框架在將來會變成什么樣子。
Bruce Eckel：極限編程(The Extreme Programmers)上說：“用最簡單的辦法來完成工作。”
Anders Hejlsberg：對呀，愛因斯坦也說過：“盡可能簡單行事。”對于Checked Excpetions特性，我最關心的是它可能給程序員帶來哪些問題。試想一下，當程序員調用一些新編寫的有自己特定的異常拋出句法的API時，程序將變得多么紛亂和冗長。這時候你會明白Checked Exceptions不是在幫助程序員，反而是在添麻煩。正確的做法是，API的設計者告訴你如何去處理異常而不是讓你自己想破腦袋。
2、Checked Exceptions的版本相關性
Bill Venners：你提到過Checked Exceptions的擴展性和版本相關性這兩個問題。現在能具體解釋一下它們的意思么？
Anders Hejlsberg：讓我首先談談版本相關性，這個問題更容易理解。假設我創建了一個方法foo，并聲明它可能拋出A、B、C三個異常。在新版的foo中，我要增加一些功能，由此可能需要拋出異常D。這將產生了一個極具破壞性的改變，因為原來調用此方法時幾乎不可能處理過D異常。
也就是說，在新版本中增加拋出的異常時，給用戶的代碼帶來了破壞。在接口中使用方法時也有類似的問題。一個實現特定功能的接口一經發布，就是不可改變的，新功能只能在新版的接口中增加。換句話說，就是只能創建新的接口。在新版本中，你只有兩種選擇，要么建立一個新的方法foo2，foo2可以拋出更多的異常，要么在新的foo中捕獲異常D，并轉化為原來的異常A、B或者C。
Bill Venners：但即使在沒有Checked Exceptions特性的語言中，（增加新的異常）不是同樣會對程序造成破壞么？假如新版foo拋出了需要用戶處理的新的異常，難道僅僅因為用戶不希望這個異常發生，他寫代碼時就可以置之不理嗎？
Anders Hejlsberg：不，因為在很多情況下，用戶根本就不關心（異常）。他們不會處理任何異常。其實消息循環中存在一個最終的異常處理者，它會顯示一個對話框提示你程序運行出錯。程序員在任何地方都可以使用try finally來保護自己的代碼，即使運行時發生了異常，程序依然可以正確運行。對于異常本身的處理，事實上，程序員是不關心的。
很多語言的throws語法（如Java），沒必要地強迫你去處理異常，也就是逼迫你搞清楚每一個異常的來源。它們要求你要么捕獲聲明的異常，要么將它們放入throws語句。程序員為了達到這個要求，做了很多荒謬可笑的事情。例如他們在聲明每個方法時，都必須加上修飾語：“throws Exception”。這完全是在搧這個特性的耳光，它不過是要求程序員多作些官樣文章，對誰都沒有好處。
Bill Venners：如此說來，你認為不要求程序員明確的處理每個異常的做法，在現實中要適用得多了？
Anders Hejlsberg：人們為什么認為（顯式的）異常處理非常重要呢？這太可笑了。它根本就不重要。在我印象中，一個寫得非常好的程序里，try finally和try catch語句數目大概是10：1。在C#中，也可以使用和類似try finally的using語句（來處理異常）。
Bill Venners：finally到底干了些什么？
Anders Hejlsberg：finally保證你不被異常干擾，但它不直接處理異常。異常處理應該放在別的什么地方。實際上，在任何一個事件驅動的（如現代圖形界面）程序中，在主消息循環里，都有一個缺省的異常處理過程，程序員只需要處理那些沒被缺省處理的異常。但你必須確保任何異常情況下，原來分配的資源都能被銷毀。這樣一來，你的程序就是可持續運行的。你肯定不希望寫程序時，在100個地方都要處理異常并彈出對話框吧。如果那樣的話，你作修改時就要倒大霉了。異常應該集中處理，并在異常來臨處保護好你的代碼。
3、Checked Exceptions的擴展性
Bill Venners：那么Checked Exceptions的擴展性又是如何呢？
Anders Hejlsberg：擴展性有時候和版本性是相關的。 在一個小程序里，Checked Exceptions顯得蠻迷人的。你可以捕捉FileNotFoundException異常并顯示出來，是不是很有趣？這在調用單個的API時也挺美妙的。但是在開發大系統時，災難就降臨了。你計劃包含4、5個子系統，每個子系統拋出4到10個異常。但是（實際開發時），你每在系統集成的梯子上爬一級，必須被處理的新異常都將呈指數增長。最后，可能每個子系統需要拋出40個異常。將兩個子系統集成時，你將必須寫80個throw語句。最后，可能你都無法控制了。
很多時候，Checked Exceptions都會激怒程序員，于是程序員就想辦法繞過這個特性。他要么在到處都是寫“throws Exception”，要么——我都不知道自己看到多少回了——寫“try, da da da da da(譯者注：意思是飛快的寫一段代碼), catch curly curly(譯者注：即‘{ }’)”，然后說：“哦，我會回頭來處理這些空的異常處理語句的。”實際上，理所當然的沒有任何人會回頭干這些事情。這時候，Checked Exceptions已經造成系統質量的極大下降。
所以，你可能很重視這些問題，但是在我們決定是否將Checked Exceptions的一些機制放入C#時，卻是頗費了一番思量的。當然，知道什么異常可能在程序中拋出還是有相當價值的，有一些工具也可以作這方面的檢查。我不認為我們可以建立一套足夠嚴格而嚴謹的規則（來完成異常檢查），因為（異常）還可能是編譯器的錯誤引起的呢。但是我認為可以在（程序）分析工具上下些功夫，檢測是否有可疑代碼，是否有未捕獲的異常，并將這些隱藏的漏洞給你指出來。
三
1、Simplicity和Simplexity
Bill Venners：C#和Java傳遞對象事件的方式有所不同。Java使用類（通常是內部類(inner classes)，它實現監聽接口（listener interfaces）。C#使用了委托（delegates。譯者注：VJ++6.0就引入了delegates），它有點兒類似函數指針。為什么要采用委托方式呢？
Anders Hejlsberg：請允許我首先談談對于一般意義上的Simplicity的看法。沒有任何人懷疑簡單的正確性，但是在如何實現簡單的問題上則千差萬別。有一種簡單，我想稱之為Simplexity。你做了一個很實際上復雜的東西，當你將它包裝為一個簡單的東西時，通常是將它的復雜性隱藏起來。所以實際上，你并不是在設計一個真正簡單的系統。這樣的一個包裝過程，從某些角度上看，系統可能被你搞得更復雜了，因為用戶有時候需要知道被隱藏地東西。這就是我說的Simplexity。
對我而言，簡單必須是真正的簡單，也就是說，當你將來某個時候需要鉆研系統內部結構時，它應該顯得更加簡單，而不是比它表面那個樣子更復雜。
2、委托和接口
Anders Hejlsberg：委托提供了與類和接口無關的實現方式，這是我認為最重要的地方。過去的很多編程語言已經認識到了這種方式的重要性。這種方式有很多名字，如：函數指針、成員函數指針，在Lisp語言中，被稱為closures， 它是非常有用處的。
Bill Venners：那么這是如何實現的呢?
Anders Hejlsberg：使用接口的確可以完成委托具有的所有功能，但是你會被迫面對煩雜的“家務管理”。我們可以對比一下Java和.NET處理事件的過程。因為在Java中沒有委托，所以最終必須使用接口。
接口是對應于事件的，一個接口可以定義1、2、3、4個甚至更多的方法。這點就已經產生了問題，因為這個“對應”沒有明確的規范。到底應該定義多少個接口來處理事件呢？是每個事件對應一個接口還是所有的事件用一個接口？讓你難以取舍。好了，先胡亂選擇其一去處理組件的事件。接下來，你必須實現這些接口。理所當然的，如果處理兩個組件的同樣的事件，你就必須將接口實現兩次——你當然不愿意這么干，所以在這種情況下，你還需要創建一個適配器。這樣，煩雜的“家務管理”就跑到你面前來了。
內部類在處理家務事上能幫點小忙，但最終，有些問題你是逃避不了的——事件接收者必須知道它什么時候接收事件。這樣你又必須明確的實現一個監聽接口。與此相反，如果你使用委托，只要信息是兼容的，你就可以將所有事件放在一起處理。這家伙并不關心自己是怎么被調用的，它僅僅是一個（處理事件的）方法。
Bruce Eckel：看來，委托是非常精瘦的。
Anders Hejlsberg：對，的確如此。
Bruce Eckel：它也更加靈活。
Anders Hejlsberg：的確是這樣。它僅僅依賴于信息的兼容性，如參數是否一致。如果是兼容的，你就可以將多個事件放在一起處理。從概念上說，這也完全滿足了用戶對一個回調的結果期望，對吧？只要給我一些參數，我就可以編寫程序了。聽起來很像一個方法吧，那么我給定該方法的一個引用，這個引用就是我所說的委托了。
Bruce Eckel：最后你也不會丟掉類型檢查。類型檢查是在運行時進行的么？
Anders Hejlsberg：不，大多數都是在編譯時進行。你創建一個委托的實例后，它就和程序員在C++中使用的成員函數指針差不多。委托指向了某對象的一個方法。如果是虛擬的方法，你也能準確地判斷委托的指向。所以從某種意義上說說，你可以在實例化委托時就解決虛擬問題。通過委托實現的調用可以看作一個間接的（方法）調用指令。
Bruce Eckel：除此之外，就不再需要其他的間接支持了。
Anders Hejlsberg：是的，構造一個委托的時候，你就可以一次性解決虛擬函數表（VTBL）和委托的指向問題；通過委托實現的調用都可以直接準確的得到它對應的方法。所以，委托比接口派遣更有效率，即使和標準的方法派遣相比，它的效率也要高一些。
Bruce Eckel：C#中也有Multicast類型的委托（譯者注：Multicast即多點傳送。是指一個委托可以對應多個方法；委托被調用時，就可以引起多個方法的調用。更詳細的說明可以參考：http：//msdn.microsoft.com/vjsharp/productinfo/
visualj/visualj6/technical/articles/general/delegates/）， 它能夠使多個函數被調用。 這是一個orthogonal特性嗎？
Anders Hejlsberg：Multicast是一個徹頭徹尾的orthogonal特性。老實說，在Multicast是否重要這個問題，我也是持保留態度的。我承認它有它的用處，但保守地講的話，我認為所有的委托都是single cast的。有些人覺得Multicast十分重要，使用它有很多優點，但是在大多數情況下委托恰恰都是single cast的。事實上，我們構造的（C#）系統是使用single cast的，只要你（在這個系統里）不使用Multicast，就不會為它付出什么代價的。
Bill Venners：委托是怎么來體現你前面所說的 Simplicity和 Simplexity的呢？它們都體現在哪些地方？
Anders Hejlsberg：如果你仿效接口來實現委托，那么你最終無可避免地要面對“家務管理”和適配器問題。其實，我們可以觀察任何一個捆綁了JavaBeans的開發工具，它們都會生成一些適配器并告訴你：“你不要修改下面的代碼，我會分發一些非常瘦小的幫助類給你。”這對于我來說就太復雜了。它并不是一個真正簡單的系統，它實際上非常復雜，不過是貌似簡單而已。
3、組件概念在C#中的至高地位
Bill Venners：O'Reilly網站發布過對于你的一次采訪，當時你這么評價C#對于屬性和事件的支持：“現在，程序員人員每天都在開發大量的軟件組件。他們不是在開發彼此孤立的應用程序和類庫。每個人都在開發繼承自環境提供的組件的新組件。這些新組件覆蓋了父組件的一些方法、屬性，處理一些事件，然后將這些新組件放回去（到組件庫）。這是一個首先要樹立的概念。”
我希望能更好理解你的談話精神，因為我一直認為我是在開發類而不是組件。你是說很多人都在為別人開發在Delphi、VB和Java中使用的組件么？你說的“組件”到底是什么呢？
Anders Hejlsberg：“組件”一詞包含的最重要的意思是組件可以很好的移植。這聽起來十分美妙，但我們可能對此有不同的理解。在一個最簡單的form中，一個組件可能就等同于一個附加了一些數據的類。組件是一個獨立的軟件部件，并不僅僅包含代碼和數據。它是一個通過屬性、方法和事件來實現自我暴露的類；是一個包含了元數據、命名模式等很多附加特征的類。這些特征可以給特定的開發環境提供動態信息，如：組件怎么使用，組件如何持久化自己的數據。開發環境使用組件的元數據就能夠實現組件功能的智能解釋并給出相應的說明文檔。“組件”包含了如上所述的全部（內容）。
Bill Venners：我使用Java作開發時想到的是，我是在開發類庫而不是組件庫，可能是因為我覺得get/set太笨重了。在激發事件的時候，我也使用get/set，但我沒有打算將這些類拿到集成開發環境中去使用，我一直想象這些類就是給那些那些純編碼的人們使用的。所以我很想知道現在到底有多少人在開發類似JavaBean那樣的組件，面向組件開發是否是未來的趨勢，因為在我的職業生涯中，和組件打的交道太少了。
Anders Hejlsberg：當今，主流的面向對象編程語言實際上都是混血兒。其中有大量的結構化編程，對象基本上也不過是一個包含了一系列方法和一個this指針的結構體。當你想到一個對象或者組件時，我想，從概念來說，你應該意識到它是有屬性和事件的。如果編程語言能給予這些概念頭等待遇的話，理解它就要容易一些。
有人可能說，C#對于屬性和事件的支持不過就是個“甜果”（譯者注：原文為syntactic sugar。Peter Landin發明的一個術語，意思是“增加到語言中、讓人們感覺更舒服的特性”）而已。其實它的確就是個甜果，對不對？哼，對象本來就是個甜果嘛。我們不過就是在那些虛擬函數表（VTBL）上打轉，你用C語言的宏也能實現，對吧？真的，你可以用C語言來面向對象編程，不過它的紛繁復雜能讓你墜入地獄。同樣的，你可以在C++或者Java里編寫組件，但是因為這些語言沒有給予組件概念足夠重要的地位，所以要痛苦得多。還得說明一下的是，屬性，并不是真的是一個屬性，而是getBla和setBla（兩個方法）。在屬性觀察器中，你看到的是Bla，但你應該知道它內部映射到了get/set。
很明顯，組件導向是大勢所趨。我們就是通過組件來使用我們的類的，但是在大多數語言中，組件并沒有成為最重要的概念。我想強調的是，組件應該擁有頭等地位。對于PME編程模式——屬性、方法、事件——的談論已經持續了很長的時間，我們也都在日復一日的使用這些東西來編程，那為什么不在編程語言中給予它應有的至高待遇呢？
附注：Anders Hejlsberg簡歷
Anders Hejlsberg是Microsoft公司卓越的軟件工程師，領導設計了C#（發音為“C Sharp”）編程語言。Hejlsberg于上個世紀80年代初投身軟件事業，為MS-DOS和CP/M平臺開發了Pascal編譯器。成立不久的一家小公司——Borland——很快聘用了Hejlsberg并收購了他的編譯器，然后改名為Turbo Pascal。Hejlsberg接下來領導開發了Turbo Pascal的替代產品：Delphi。1996年，Hejlsberg在為Borland工作13個春秋后，加盟Microsoft公司（譯者注：因為Borland公司內部矛盾和Microsoft的殷勤）。
轉自http://www.cnitblog.com/sugar/archive/2006/03/19/7773.html
[人物介紹]
Anders Hejlsberg，微軟著名工程師，帶領他的小組設計了C#（讀作：C-Sharp）程序設計語言。Hejlsberg第一次登上軟件界歷史舞臺是在80年代早期，因為他為MS-DOS和CP/M設計了Pascal編譯器。當時，還是一個小公司的Borland很快雇用了他，并買下了他的編譯器，改稱Turbo Pascal。在Borland，Hejlsberg繼續開發Turbo Pascal，并最終帶領他的小組設計了Turbo Pascal的替代品：Delphi。1996年，在進入Borland 13年后，Hejlsberg加入了微軟。最初，他做Visual J++和Windows Fundatioin Classes（WFC）的架構師。隨后，Hejlsberg成為C#的首席設計師和.NET Framework的關鍵參與者。目前，Anders Hejlsberg還在領導著C#程序設計語言的繼續開發。
Bruce Eckel，Think in C++（C++編程思想）和Think in Java（Java編程思想）的作者。
Bill Venners，Artima.com的主編。
[內容]
一、泛型概述
二、C#中的泛型
三、C#泛型和java泛型的比較
四、C#泛型和C++模板的比較
五、C#泛型中的約束
一、泛型概述
Bruce Eckel：您能對泛型做一個快速的介紹么？
Anders Hejlsberg：泛型其實就是能夠向你的類型中加入類型參數的一種能力，也稱作參數化的類型或參數多態性。最著名的例子就是List集合類。一個List是一個易于增長的數組。它有一個排序方法，你可以為它做索引，等等。現在，如果沒有參數化的類型，那么不論使用數組還是使用List都不是很好。如果你使用數組，你能獲得強類型，因為你可以聲明一個 Customer類型的數組，但你失去了可增長性和那些方便的方法；如果你使用一個List，你能夠得到所有的便利，但你失去了強類型。你難以說出一個 List是什么（類型的）List，它只是一個Object的List【譯注：“什么類型的List”指的是List存放的元素是什么類型的】。這會給你帶來麻煩，因為類型只能在運行形時進行檢查，也就是說在編譯時不會進行類型檢查。就算你硬要把一個Customer放進一個List并試圖從中得到一個 String，編譯器也不會不高興。在運行之前你根本無法發現它不能工作。同時，當你將簡單類型【譯注：指值類型】放入List時，還必須對它們進行裝箱。正是由于這些問題，你不得不在List和數組之間徘徊，你經常要很痛苦地決定應該使用哪一個。
泛型的偉大之處在于你現在可以盡情地享受你的蛋糕了，因為你能夠定義一個List<T>（讀作：List of T）【譯注：中文可以說成“T類型的List”】。當你使用List時，你居然能夠說出它是什么類型的List，并且你將獲得強類型，編譯器會為你檢查它的類型。這些只是直覺上的好處，它還有其它許多優點。當然，你并不是只能將它用于List，Hastable、Dictionary（將鍵影射到值上的數據結構）——所有你想調用的都行。你可能想將String影射到Customer、將int影射到Order，在這些情況下你都能獲得強類型。
二、C#中的泛型
Bill Venners：泛型在C#中是如何工作的呢？
Anders Hejlsberg：在沒有泛型的C#中，你只能寫class List {...}；而在帶有泛型的C#中，你可以寫class List<T> {...}，這里的T是一個類型參數。在List<T>中，你可以把T就當作一個類型來用。當它實際用來建立一個List對象時，你要寫 List<int>或List<Customer>。這樣你就從List<T>構造了一個新的類型，看起來就好像你用你的類型變量替換了所有的類型參數。所有的T都變成了int或Customer，你無須進行向下轉換，它們是強類型的，任何時候都會被檢查。
在 CLR（Common Language Runtime，公共語言運行時）中，當你編譯List<T>或其它泛型類型時，它們和普通類型一樣被轉換為IL（Intermediate Language，中間語言）和元數據。IL和元數據帶有附加信息，可以知道這是一個類型參數，當然，原則上泛型類型的編譯和其它類型一樣。在運行時，當你的應用程序第一次引用List<T>時，系統會看看你是否已經使用過List<int>。如果沒有，它會調用JIT將帶有 int類型變量的List<T>編譯為IL和元數據。當JIT即時編譯IL時，同樣會替換類型參數。
Bruce Eckel：所以它是在運行時被實例化的。
Anders Hejlsberg：它確實是在運行時實例化。它在需要的時候才產生特定的原生代碼（native code）。字面上，當你說List<T>時，你會得到一個int類型的List。如果泛型類型中使用的是T類型的數組，它會變成int類型的數組。
Bruce Eckel：這個類會在某一時刻被垃圾收集器收集么？
Anders Hejlsberg：是也不是，這是一個正交的問題。它會在該程序集中建立一個類，這個類在程序集中會一直存在。如果你終止了程序集，這個類會消失，和其它類一樣。
Bruce Eckel：但如果我的程序中聲明了一個List<int>和一個List<Cat>，但我從未使用過List<Cat>……
Anders Hejlsberg：…… 那么系統不會實例化List<Cat>。當然，下面的情況除外。如果你使用NGEN產生一個鏡像，也就是說如果你預先生成了一個原生代碼的鏡像，會預先實例化。但是如果你在一般的環境下運行，則這個實例化是純需求驅動（demand driven）的，會盡可能地延遲【譯注：正如上面所說，直到使用時才進行實例化】。
實際上，我們所要進行實例化的所有類型都是值類型——如List<int>、List<long>、List<double>、 List<float>——我們為每一個都建立一份唯一的可執行原生代碼的拷貝。因此，List<int>有它自己的代碼，List<long>有它自己的代碼，List<float>有它自己的代碼。對于所有的引用類型我們共享它們的代碼，因為它們在表現上是一樣的，它們只是一些指針。
Bruce Eckel：因此你只需要轉換。
Anders Hejlsberg：不，實際上是不需要的。我們可以共享原生鏡像，但他們實際上具有獨立的VTable。我要指出的是，我們只是盡量對代碼進行有意義的共享，但我們很清楚，為了效率，有很多代碼是不能共享的。典型的就是值類型，你會很關心List<int>中到底是不是int。你肯定不希望將它們被裝箱為 Object。對值類型進行裝箱是一種共享的方法，但對它們進行裝箱開銷會很大。
Bill Venners：對于引用類型，所不同的只是類。List<Elephant>不同于List<Orangutan>，但他們實際上共享了所有方法的代碼。
Anders Hejlsberg：是的。作為實現的細節，它們實際上共享了相同的原生代碼。
三、C#泛型和java泛型的比較
Bruce Eckel：如何比較C#中的泛型和java中的泛型呢？
Adners hejlsberg：Java 的泛型最初是基于Martin Odersky和其它人一起做的稱作Pizza的一個項目的。Pizza后改名為GJ，然后成為JSR，最后以被Java語言收容而告終。這種泛型以能夠在原有的VM（Virtual Machine，虛擬機）上運行為關鍵設計目標。也就是說，你不必修改你的VM，但它會帶來很多限制。這些限制并不會很快出現，但很快你就會說：“嗯，這有點陌生。”
例如，使用Java泛型，我覺得你實際上不會獲得任何的執行效率，因為當你編譯一個Java泛型類時，編譯器會將所有的類型參數替換為Object。當然，如果你嘗試建立一個List<int>，你就需要對所有的int進行裝箱。因此，這會有很大的開銷。另外，為了讓VM高興，編譯器必須為所有的類型插入類型轉換。如果一個List是Object的，而你想將這些Object視為 Customer，就必須將Object轉換為Customer，以讓類型檢查器滿意。而它在實現這些的時候，真的只是為你插入所有這些類型轉換。因此，你只是嘗到了語法上的甜頭，卻沒有獲得任何執行效率。所以我覺得這是（泛型的）Java實現的頭號問題。
第二號問題，我覺得也是一個很嚴重的問題，這就是由于Java泛型是依靠消除所有的類型參數來實現的，你就無法在運行時獲得一個和編譯時同樣可靠的表現。當你在 Java中反射一個泛型的List的時候，你無法得知這是個List什么類型的List。它只是一個List。因為你失去了類型信息，任何由代碼生成方案或基于反射的方案所產生的動態類型都將無法工作。唯一讓我認為清晰的趨勢就是，越來越多的東西將不能運行，就是因為你丟掉了類型信息。但在我們的實現中，所有這些信息都是可用的。你可以使用反射來獲得List<T>對象的System.Type。但你還不能建立它的一個實例，因為你并不知道T 是什么。但是接下來你可以使用反射來獲得int的Sytem.Type。然后你就可以請求反射將這兩個System.Type結合起來并建立一個 List<int>，然后你還能獲得List<int>的另一個System.Type。因此，所有你在編譯期間能做的在運行時同樣可以。
四、C#泛型和C++模板的比較
Bruce Eckel：如何比較C#泛型和C++模板呢？
Anders Hejlsberg：我認為對C#泛型和C++模板之間的區別最好的理解是：C#泛型更像類，只不過它帶有類型參數；C++模板接近宏，只不過它看起來像類。
C# 泛型和C++模板之間最大的區別在于類型檢查發生的時機和如何進行實例化。首先，C#在運行時進行實例化。而C++在編譯時，或者可能是連接時進行實例化。不管怎么說，C++是在程序運行前進行實例化。這是第一點不同。第二點不同是當你編譯泛型類型時，C#會進行強類型檢查。對于一個非約束的類型參數，如List<T>，能夠在類型為T的值上執行的方法僅僅是那些能夠在Object類型中找到的方法，因為只有這些方法是我們能夠保證存在的。在C#中，我們要保證在一個類型參數上執行的所有操作都能成功。
C++正相反。在C++中，你可以在類型參數所指定的類型的變量上執行你想做的任何操作。但是一旦你對它進行了實例化，它就有可能無法工作，你將會得到一些含義模糊的錯誤信息。例如，如果你有一個類型參數 T，而x和y是T類型的變量，然后你執行x+y，如果你對兩個T定義了一個operator+還好說，否則你就只能得到一些沒意義的錯誤消息。因此，從某種意義上說，C++模板實際上是無類型的，或者說是弱類型的。而C#泛型是強類型的。
五、C#泛型中的約束
Bruce Eckel：約束是如何在C#泛型中工作的呢？
Anders Hejlsberg：在C#泛型中，我們能夠為類型參數施加約束。以我們的List<T>為例，你可以說class List<T> where T : IComparable。這意味著T必須實現IComparable接口。
Bruce Eckel：有意思。在C++中，約束是隱式的。
Anders Hejlsberg：是的。在C#中我們也可以這樣做。譬如我們有一個Dictionary<K, V>，它有一個Add()方法，這個方法帶有K key和V value參數。Add()方法的實現將希望能夠將傳遞進來的key和Dictionary中已經存在的key進行比較，而且它希望使用一個稱作 IComparable的接口。唯一的途徑就是將key參數轉換為IComparable接口，然后調用CompareTo方法。當然，當你這么做的時候，你就為K類型和key參數建立了一個隱式的約束。如果傳遞進來的key沒有實現IComparable接口，你會得到一個運行時錯誤。這在你的所有方法中都有可能出現，因為你的約定沒有要求key必須實現IComparable接口。當然，你還得為運行時類型檢查付出代價，因為你實際上進行了動態類型轉換。
使用約束，你可以消除代碼中的動態檢查，而在編譯時或裝載時進行。當你要求K必須實現IComparable接口時，會發生很多事情。對于K類型的值，你現在可以直接訪問接口方法而無需類型轉換。因為程序在語義上可以保證它實現了這個接口。無論什么時候你嘗試建立這個類型的一個實例時，編譯器都會檢查這些類型是否實現了這個接口，如果沒有實現，會給你一個編譯錯誤。如果你使用的是反射，你會得到一個異常。
Bruce Eckel：你是說編譯器和運行時（都會進行檢查）？
Anders Hejlsberg：編譯器會檢查它，但你仍有可能在運行時通過反射來做這些，因此系統還會檢查它。正像我前面說的，編譯時可以做的任何事都可以在運行是通過反射來做。
Bruce Eckel：我可以做一個函數模板，換句話說，一個帶有不知道類型的參數的函數？你為約束添加了強類型檢查，但我是不是能像C++模板那樣得到一個弱類型模板？例如，我能否寫一個函數，它帶有兩個參數A a和B b，并在代碼中寫a+b？我能不能說我不在乎對于A和B是否有operator+，因為它們是弱類型的？
Anders Hejlsberg：你真正要問的問題應該是這在約束中如何說吧？約束，和其他特性一樣，最終將可以是任意復雜的。當你考慮它的時候，約束只是一個模式匹配機制。你可能希望能夠說“這個類型參數必須有一個帶有兩個參數的構造器、實現了operator+、有這個靜態方法、有那兩個實例方法、等等”。問題是，你希望這種模式匹配機制有多復雜？
從沒有任何東西到完全模式匹配是一個整個的連續體。沒有任何東西（的模式匹配）太小了，不能說明問題；而完全模式匹配又太復雜了，因此我們需要在中間找一個平衡點。我們允許你將約束指定為一個類、一個或多個接口，以及一些構造器約束。譬如，你可以說：“這個類型必須實現IFoo和IBar”或“這個類型必須繼承基類X”。一旦你這么做了，在編譯時和運行時都會檢查這個約束是否為真。這個約束所隱含的任何方法對于類型參數所指定的類型的值都是直接有效的。
現在，在C#中，運算符是靜態成員。因此，運算符不能是接口的成員，因此接口約束不能帶給你operator+。你只能通過類約束獲得operator+，你可以說這個類型參數必須繼承自比如說Number類，并且 Number類對于兩個Nubmer有operator+。但你不能抽象地說“必須有一個operator+”，我們無法知道這句話的具體含義。
Bill Venners：你通過類型進行約束，而不是簽名。
Anders Hejlsberg：是的。
Bill Venners：因此這個類型必須擴展一個類或實現一個接口。
Anders Hejlsberg：是的。而且我們還能夠走得更遠。實際上我們也想過再走遠一些，但這會變得相當復雜。而且增加的復雜性與所得到的相比很不值得。如果你想做的事情在約束系統中不直接支持，你可以使用一個工廠模式。例如你有一個Martix<T>，而在這個Martix（矩陣）中，你可能想定義一個“點乘”【譯注：矩陣上的一種乘法運算，另一種稱為“叉乘”】方法。這意味著你最終將要考慮如何將兩個T相乘，但你不能將這說成是一個約束，至少當T不是int、 double或float時你不能這么說。但你可以讓你的Martix帶有一個Calculator<T>作為參數，而在 Calculator<T>中，有一個稱為Multiply的方法。你可以在其中進行實現，并將結果傳遞給Martix。
Bruce Eckel：而且Calculator也是一個參數化的類型。
Anders Hejlsberg：是的。這有些像工廠模式，還有很多方法可以做到，這也許不是你最喜歡的方法，但做任何事情都要付出代價。
Bruce Eckel： 是呀，我開始認為C++模板是一種弱類型機制。而當你想其中添加了約束后，你從弱類型走向了強類型。但這一定會帶來更多的復雜性。這就是代價吧。
Anders Hejlsberg： 關于類型你可以認為它是一個標尺。這個標尺定得越高，程序員的日子就會越不好過，但更高的安全性隨之而來。但你可以把這個標尺向任何一個方向調節。