Eric E. Allen (eallen@cs.rice.edu), 博士研究生候选人, Rice University

2001 年 9 月 04 日

在 诊断 Java 代码 的这个部分和即将到来的几个部分中，Eric Allen 将他的讨论集中在判断一个新系

统应该有多大的可扩展性、什么时候应用可扩展性是最佳的以及可扩展性与其它因素（特别是可测试性）

的关系如何。在这第一篇文章中，他研究了能使一个软件系统具有可扩展性的各种方法以及每种形式的可

扩展性各在什么样的环境中最有用。请在 讨论论坛与作者和其他读者交流本文的心得。
随着对能应付日益增长的各种信息处理任务的软件系统需求的增长，找到能降低新的代码项目的生产成本

的办法对软件公司是一种诱惑。最明显的办法之一是提高其它项目的代码的可重用程度。

在程序员设计一个新系统时，由此出现的更常见的问题中的两个是：

系统应该有多大的可扩展性？
我能使系统具有多大的可扩展性？
如果原始系统被设计成可扩展的，那么重用代码是最佳的办法。否则，重用代码时碰到的困难可以容易地

抵消任何已获得的生产率。但是，要设计成可扩展的，在软件设计中就要考虑各种各样的新问题。

可扩展性的类型

黑箱可扩展性。扩展现有系统而不 直接扩展其原始代码，一般是通过向导或配置语言。 例如：任何支持

用户定义脚本或宏的程序。
白箱可扩展性。通过以下两种方式往源代码添加代码扩展现有程序：
开放箱可扩展性。原始源代码可以查看和修改。 例如：开放源代码的程序。注意：当源代码由外界维护

时，将会出现问题；您可能不得不不断地拒绝扩展而对程序进行新的重复。
玻璃箱可扩展性。源代码可以查看，但不能修改。 例如：一些测试程序，如 JUnit。（尽管您无法修改

JUnit 的源代码，但您用 JUnit 构造的每个测试就象是一个对基础代码的扩展。）
 
 
我将在本文讨论一些办法，这些办法能使一个软件系统对将来的项目是可扩展的。

忠告

在进行任何努力之前，请让我澄清一下，我不是主张在所有情况或者甚至大多数情况下都为了可扩展性进

行设计。有利于许多设计的可扩展性选择常常会妨碍其它需要考虑的因素，例如性能或可测试性。可测试

性最好的系统常常也是最简单的系统，但可扩展性设计却常常会大大增加系统的复杂性。

幸运的是，也有可扩展性最好的设计也是最简单的设计的时候，但能兼顾二者的时候真是太少了。

因为这个原因，我建议只在您能肯定得益会大于花费时才采用可扩展性策略。这通常意味着您 知道系统

将会被以一定的方式扩展。

在极端编程著作中，常常把可扩展性的收益和购买股票期权相比较：您早先购买了期权，因此在将来您可

以容易地扩展系统。如果最终您行使了这一期权，则可以获利颇多。

但如果您从未行使这一期权，则您将损失掉期权的价格并且没有任何回报。所以，“买主须谨慎！”

下面，我们来看看术语 可扩展性的各种定义方式。当讨论程序的可扩展性时，我们所指的本质上有三种

不同类型 ― 黑箱可扩展性和两种类型的 白箱可扩展性。 图 1说明了可扩展性类型的差别。

黑箱可扩展性

黑箱可扩展性是指这样一种方式：不直接扩展原始代码即可扩展程序。这通常通过使用配置语言或向导来

完成，向导引导您完成对系统的扩展。

税务程序就是一个示例，这个程序包含一种配置语言，用于指定各种税务申报表。当政府发布新的税收申

报表时，只需通过用配置语言说明新的税收申报表的结构即可扩展该系统。

黑箱可扩展性最适合用于研究这样的专有组件和框架，这里原始开发小组的业务模式要求两条：

程序是专有的（非开放源代码）
外界开发者在定制组件的功能性方面有一定程度的灵活性
支持用户定义脚本或宏的程序（如 Emacs、MS Office 等等）就是具有黑箱可扩展性的系统的示例。

白箱可扩展性

白箱可扩展性，相反地，是指可以通过修改或添加源代码对程序进行扩展的方式。我喜欢把白箱可扩展性

区分为两个子类型： 开放箱和 玻璃箱。

开放箱可扩展性

当允许对原始源代码进行修改时，我称这个系统是开放箱可扩展的。当然，原则上说，这样的程序可以任

意扩展，但不是所有的扩展难度都一样。

对开放箱可扩展性的研究主要涉及在必要的时候如何在给定的修改程序能力下使各种各样的扩展更容易。

这种形式正是与开发小组在生产他们自己产品的下一版本时关系最大的可扩展性形式。

在有些情况下，这种类型的可扩展性也是想利用现有的开放源代码软件的开发者的兴趣所在。但以这种方

式扩展开放源代码系统会碰到诸多问题。

最大的问题是当“官方”维护小组决定发布该软件的一个新版本时该怎么办。把他们的更改和您的更改熔

合起来可能既困难又费时。 即使该系统是充分模块化的，足以使您已更改的实际代码也不冲突，要确保

新代码预设的不变量未被您的更改破坏掉也是困难的（尽管如果代码带有单元测试，这个问题可以得到很

大改善）。

玻璃箱可扩展性

玻璃箱可扩展性是指这样一种方式：当可以查看源代码，但不能修改时，用此种方法可以扩展软件系统。

因为上面所讨论的涉及改动外界维护的开放源代码代码的问题，所以在任何有必要的时候对这种代码只使

用玻缡箱扩展是明智的。流行的、玻璃箱可扩展的系统的一个很棒的示例是 JUnit。每一个单元测试都可

看作是原始代码基础的一个扩展。

关于箱的更多内容

这些不同类型的可扩展性各适用于一定的环境，其中的一些环境我已经谈到过。例如，在专有软件允许“

外界”开发者对程序进行扩展（但不允许查看底层代码）的情况下，黑箱方案是合适的。

当要将底层代码开放以进行查看或修改时，白箱方式中的一种是合适的。

每一种情形，当然，都有它自己衍生的软件设计方面的问题。此外，在一个给定的系统中，可能会用到不

止一种可扩展性形式。

在下一部分中，我将继续这个讨论，研究与白箱可扩展性有关的问题。在以后的文章中，我将剖析使用多

种可扩展性类型的系统的示例。

参考资料

参加本文的 讨论论坛。

ACM Web 站点上的文章“ Object-Oriented Framework Development”讨论各种类型的重用在框架中的应

用。

Clemens Szyperski 的 Component Software: Beyond Object-Oriented Programming （Addison-Wesley

，1998）是关于由可重用组件组成的系统的设计的信息的很好的硬拷贝资源。

JUnit 主页提供讨论程序测试方法的很多有趣文章的链接，并提供 JUnit 的最新版本。

要获得关于扩展 Java 应用程序的讨论，看看 Doug Tidwell 的免费教程“ XML programming in Java”

（developerWorks，1999 年 9 月），这篇教程集中讨论编写用 XML 解析器操作 XML 文档的 Java 代码

。

文章“ Java Beans In, Java Beans Out”（developerWorks，1998）提供了一个使用 JavaBean 技术完

成黑箱实现的示例。

“ Using IBM SanFrancisco Business Components with VisualAge for Java”提供在 IBM 的集成开发

环境中使用可重用的服务器端应用程序业务组件的概述。

Dennis Sosnoski 的“ Java performance programming: Smart object-management saves the day”（

developerWorks，1999 年 12 月）讨论 Java 对象重用的两类机制 ― 简单快速的 专用对象重用和高效

的 自由池方案。

阅读 Eric 诊断 Java 代码 的所有文章。

在 developerWorks Java 技术专区上查找更多的 Java 参考资料。

关于作者

Eric Allen 从 Cornell University 获得计算机科学及数学的学士学位，并且是 Rice University

Java 编程语言小组的博士研究生候选人。在回 Rice 完成学位前，Eric 是 Cycorp，Inc. 的 Java 开发

者带头人。他还在 JavaWorld上主持“Java 初学者”讨论论坛。他的研究涉及在源程序和字节码层次上

Java 语言的语义模型和静态分析工具的开发。Eric 还帮助开发 Rice 的 NextGen 编程语言编译器，

NextGen 是一个支持泛运行时类型的 Java 扩展。可通过 eallen@cs.rice.edu与 Eric 联系。