Bjarne Stroustrup谈系统设计的原则和方法

Bjarne Stroustrup谈系统设计的原则和方法

第一部分谈了系统设计的基本原则和方法。笔者这部分认为非常精彩，大师们对于系统设
计的一般原则和方法的理解都是类似的。象笔者这种菜鸟只有拜读之后恍然大悟然后顶礼
膜拜的份了。

第二部分,第三部分谈了程序设计的风格问题，笔者认为其中关于类的设计的讨论可以说是
一针见血。任何有志于面向对象程序设计的高级程序员（无论使用何种语言开发）都应该
读一读这部分。

第四部分谈了抽象和效率的问题。其中一个重要观点就是，抽象有利于效率而不是反之。



全文：

在2003年9月的JAOO会议上，Bill Venners和Bjarne Stroustrup碰面并进行了这次谈论。

Bjarne Stroustrup是C 语言的发明人。

0. 精致以及其他设计理念（Elegance and Other Design Ideals）
Bjarne Stroustrup谈论了软件设计的许多方面。包括如何将小的软件扩展为大的软件，避
免在设计者和用户之间区分类，过早一般化（generalization）的危险和精致（elegance
）的本质等等。

0.1. 编码之前思考（Thinking Before You Code）
Bill Venners: 在和Biltek的谈话中，你说过：“我不是使用支持工具进行巧妙设计的信
徒，但是我强烈支持系统地使用数据抽象，面向对象编程，和generic programming。不拥
有支持库和模板，不进行事先的总体设计，而是埋头写下一页页的代码，这是在浪费时间
。这是给维护增建困难。”你认为进行多少事先的设计合适？编码之前我们该思考多长时
间？

Bjarne Stroustrup: 取决于问题的规模。如果你今天下午就要使用这个程序，使用信封背
面做做设计就可以了。如果你的系统需要多年才能完成，那你当然需要更多的事先设计。
项目需要的人越多，需要进行越多的设计工作。然而，系统越大，事先的设计越困难。设
计工具不能给你很多的反馈，所以我认为建立一个更小的系统，慢慢扩展更好一点。有一
个基本原则，每一个成功的大型项目都是由小项目扩展而来的。每个小项目又是由更小的
项目扩展而成的。依此类推。

有些人认为我说的是建立原型。某种程度上是的。但不全是。原型有时候可能是个陷阱。
如果原型是由完全不同的开发者使用不同的工具开发出来和真实的应用程序不同的东西，
你就会有麻烦。例如，相对于开发面向10000个客户的真实应用程序，你可以用更好的软硬
件加上更好的程序员开发面向10个客户的原型。你可以忽略一些非标准的问题。你可以忽 字串9
略兼容性问题。最后你发现，原型得到的方案无法应用到更大规模的实际应用程序上。


有时候你可以先实现系统的部分功能。但我强调尽可能早地进行集成测试。例如，写个简
单的“hello world”程序。在分布式系统上，你就为分布式系统的每台电脑都写个程序，
然后让它们交谈。于是你发现Java ORB不能和你的C ORB交谈，或者你的在sun机器上的
java虚拟机不能和HP机器上java虚拟机交谈。当然我只是举例。但是可以肯定的是，“总
”会有未料到的问题发生。我不是在谈原型。我在谈真实环境下的真实系统的试验。尽可
能早的进行这些试验。

0.2. 用库思考（Thinking in Libraries）
Bill Venners: 我经常听你宣称C 支持库的设计。哪种程度上应用程序开发者以可以认为
自己是开发库呢？我们需要把应用程序分成这个库或者那个库吗？或者你说的库就是字面
意义上会给很多人使用的库？

Bjarne Stroustrup: 我认为人们应该把编程分成库的开发和库的使用两步。今天你写支持
库，明天你使用它。但是人们很多时候不这样做。即使我一个人写一个很小的程序。我也
总是先写一些支持类和支持函数。我不喜欢直接开始写一个完整的应用程序。所以，不管
你是写应用程序还是写库，你都需要划分模块。

C 的一个问题是有太多的库，但是没有一个大卖场有所有这些库。C 不是对GUI支持不好
。C 有GUI库。问题是C 有25个GUI库。有些GUI库不错。但是人们说：“可是C 没有标
准GUI库。”Python不一样。人们知道到哪里去找Python的GUI库。所以C 的问题是有太多
库，但是所有的库市场宣传都做的不够（It´s a problem of riches, plurality, and a
lack of marketing）。搞C 的看来都很穷，没有钱来提供一个可以找到所有库的大卖场
。

绝对不能认为自己已经掌握了完美的库的设计艺术。抱着这样的态度去设计库，一定会失
败。在我开始使用你设计的库后，你认为大功告成，于是拍拍屁股走人。这可不对。库的
设计者必须是库的使用者，或者至少，设计者必须长期维护库。和用户长期交流，你才能
知道什么是正确的抽象，什么是正确的细节。库需要演化。最好的库是由库的使用者设计
的。类的使用者和设计者是两拨人，这可不对。

0.3. 哪些纳入语言标准，哪些放弃（What to Leave In, What to Leave Out）
Bill Venners: C 内容很多。语言或者库的内容越多，语言或者库的使用者越得心应手， 字串6
但是使用者必须学习的东西也多。即使为了知道哪些东西可以忽略，使用者们也必须学习
很多东西。作为C 语言和标准库的设计者，你是如何决定哪些特性放进标准，哪些忽略的
呢？

Bjarne Stroustrup: 这是很难决定的。我没有一种足够好的哲学来做决定，我想别人也没
有。在C 语言中，我试着把对所有人而不是少数人有益的特性放进标准。我试图放进标准
的是一些通用的工具。例如，我不把GUI特性放进标准。因为很多程序没有GUI界面。我不
试图增加对数据库的标准支持。因为许多人并不使用数据库。货币也不作为语言特性，因
为你可以使用支持货币的库。我尽可能使语言简洁，避免冗余，避免人们学习太多的东西
。我在模板（template），内联（inline），重载（overload）方面做的工作，消除了冗
余，消除了危险的强制类型转换。这是最好的例子。

当然，我刚才说的既可以适用于标准库的设计，也适用于语言的设计。很难简单地在库和
语言之间画一条线。我总是试图把一些能够实现抽象机制的特性加入C 语言。所以和别的