Anders Hejlsberg谈C#设计过程
原文：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(译者注：即‘{ }’)