权威设计语言时代的终结

作者简介

Michael Feathers世界级面向对象技术专家，以丰富的软件项目开发经验著称。目前在世界顶尖的软件咨询公司Object Mentor从事敏捷方法／极限编程、测试驱动开发、重构、面向对象设计、Java、c#和C++等方面的培训和项目指导。他是著名测试框架 CppUnit和FitCpp的开发者，已经主持了三次面向对象界盛会OOPSLA上的CodeFest比赛。

 

 

         今年早期,我被邀请在一个Ruby会议上发言. 我很高兴去那里,但我觉得在那里我是个外人. 我没有写过多少Ruby,但我仰慕这种语言很久了. 我有很多的朋友都放弃了C++和Java,投奔了Ruby和Python.大部分的人都很满意. 他们用这些语言做了很好的项目,而且很亨受. 他们用实际行动证实:所担心的动态语言会带来恶梦般的结果并非不可避免. 你完全可以使用动态语言编写出安全可靠、高质量的程序. 他们一直以来都这样做，但我认为这是和文化有关的。 如果你在一个文化圈内,你在圈内听到一些事情,你觉得很正常,但圈外的人听起来会觉得很奇怪. 如果你不在圈内,你也会奇怪.

对于Ruby,我现在的处境就是这样,在一定程度上。 我没有写过大型的Ruby程序. 我只是用这种语言程序进行过修改，写过一些小工具，到此为止，从来没有真正的浸润在其中。但这并不影响我在边上对这种有趣的语言保持关注。 我曾经提到过，让我感到惊奇的事情之一是Ruby迷们对这种语言的态度与众不同。 我在他们身上发现了一种在其他语言文化中不曾见过的责任道德.

              责任道德? 我说的是什么意思呢?

我 想我可以用这种方式解释清楚. 在许多的语言社团里,人们非常关心用“正确”的方法做事情. 他们知道语言里的所有缺点和优点,他们料到有些特性可能会被错用. 于是他们开始编写编程见意和程序风格指导-所有的资料都是来告诉你如何在这种语言里避免这种错误的. 这些建议不停的在增加,改进. 大部分都围绕着合法程序的缺陷问题. 因为有些编程语言真是很难让你去正确的使用. 其他的一些建议最终成为语言文化的一部分. 如果某种编程语言提供了你可以对程序设计进行强制约的方法,如果你不用,就会显得不太正确. 举个例子,我们可以看看C++和Java里的封装和final. 这两种数据定义几乎做的是相同的事情.人们也不厌其烦的告诫要去如何使用它们来保护抽象性. 可是,有趣的是,像Ruby,Python这样的语言里不存在类似的现象.但他们仍然写出了健壮的程序.

我 们先不讨论动态和静态的问题,花几分钟看看其它问题. 我觉得更重要的一个问题是风格问题. 在某些语言中你会有这样的感觉,语言的设计者会告诉你有些东西很危险,以至于你要避免用它,要用有效何工具检测这些特性是否被误用. 结果是整个语言社区把大量的时间花在写处方,提建议和变相方案上. 而且，如果这种语言不提供可以约束人们习惯错用的做法的功能，人们会很生气。

      在Ruby圈里我却没有发现这种文化。

      用Ruby，你几乎可以做你能想象到的任何事情。 你可以修改类库里的任何类，将aspect-y行为编织进去，并且可以做一些接近疯狂的meta编程。 也就是说，一切全在于你。 你对自己负责。 如果什么地方出错了，你只能责怪自己。 你不能责怪这种语言的设计，责怪它没有某种功能、导致需要你去自己实现，你也不会责怪它会阻拦你做什么事情，因为它不会阻拦你。

      所以，为什么没有很多人因此而崩溃和玩过火呢？ 我想这有一个很好的理由。 权利越大，责任越大。 你掌握自己的命运。 而且，这样，我认为，是一种提升你的责任心的方法。

多 少年来，在软件业，我们一直以为，有些语言提供的功能过于强大，很容易让开发者误用。 C++不提供反射机制， Java/C#禁止多重继承。 可是，每次，我们发现，当程序员因正当的理由要求的功能没有被提供，而采取的临时解决方案，这种做法带来的坏处比语言提供那种功能带来的坏处要大的多。 Blocks 和 closures 就是典型的例子。 今天的世界上有无数的应用都有各种重复的代码，实际上你完全可以通过模板的设计模式或者通过微型类打包变量的做法消除这些重复。 如果有了blocks 或 closures，程序员就可以消除重复，达到最洁净的程序设计效果。

Meta编程是另外一个好例 子。 商业应用里到处都有我们需要知道一段数据的值，类型，名称的情况，然而，我们的语言却让我们不得不一次次的手工编写这样的功能。 事实上，我们花了近十年的时间才发展出来像Rails里的ActiveRecord这样有用的东西，归咎其原因就是人们担心有些语言的某些功能过于强大的 心理在作怪。

我们为这种态度付出了应有的代价。 幸运的是，我们已经不再是当年的想法了。 新诞生的编程语言都把责任交给开发者自己。 但是，语言设计者们都还坚持他们的推理方式 - 他们认为有些东西就是不应该被允许。 如果你想找一个按这种方式推理的例子，请看Bruce Eckel 博客里的 metaprogramming 部分 ( http://www.artima.com/weblogs/viewpost.jsp?thread=260578 ). 我敬重 Bruce，并且我明白他并不是以一个语言设计者的身份说话，但我提到他只是作为一个这样推理类型人的例子 - 他们按照他们的逻辑推理出在一个语言里什么东西应该不被允许，而不是把控制和责任都交到编程者的手里。 也许语言设计者们把我们可能需要元数据编程的地方的95%都考虑到，并提供了方案。但这样做值不值得，而且并不等于剩下我们对其他的问题的变通方案的工作 努力只占剩下的5%。 还有额外的代价对人们对语言的责任感和拥有感的降低。 我想人类的度量方式对软件的影响要远大于人们的想象。

可这个问题的实际情况是：任何一种语言都可能产生混乱。 语言的设计者不可能阻止的了。 他们所能做的就是断定什么样的混乱可能会产生，以及产生这些混乱的难易度。 但是，在他们做定论时，他们还是迫不及待的把那些过于强大的功能给去除了。 程序员们不会这样做。 他们能为自己负责。 实际上，最终必将是，除了程序员自己，没人能负这个责。

 

外刊IT评论