** 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( 译者注：即‘ { } ’ ) ”，然后说：“哦，我会回头来处理这些空的异常处理语句的。”实际上，理所当然的没有任何人会回头干这些事情。这时候， Checked Exceptions 已经造成系统质量的极大下降。
<SPAN style="FONT-SIZE: 12pt; FONT-FAMILY: 宋体; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: