对应于我们上一篇“ 诊断 Java 代码”中所讨论的透明盒可扩展性，黑盒可扩展性是指，在源代码既不能查看也不能修改时，可以扩展软件系统的方法。通常通过系统配置或使用特定于应用程序的脚本语言来进行这样的扩展。在本专题中，Eric Allen 讨论了何时设计黑盒可 扩展性的系统是有意义的，并提供了如何有效地实现这一设计的一些想法。阅读了本文后，您将知道何时使用黑盒并掌握如何实现它的一些技巧。
我已在以前的文章中谈到了代码重用设计策略的重要性（主要是因为各种信息处理任务的差异和相应费用的增加），所以如果您已确定将系统可扩展性作为您的目标，那么请先问一下自己“系统的可扩展性应该达到什么程度，我能实现怎样的可扩展？”然后，考虑下列方面：
对添加可扩展性的权衡，因为添加扩展性可能会降低性能或测试能力。
通常，测试性最好的系统就是最简单的系统；添加可扩展性常常增加了复杂性。
规划成功的可扩展设计的一个关键知识是，要知道您计划以后如何扩展系统。
在本系列的 第一篇文章中，我曾概述了系统可以呈现的可扩展性的各种形式 ― 黑盒设计与两种 白盒设计（ 透明盒与 开放盒）。 第二篇文章中，我详细介绍了透明盒可扩展性的使用及实现，透明盒是一种恰当的介于黑盒与开放盒设计之间的设计方法。
这个月，我希望继续我们的“旅行”，展开讨论黑盒可扩展性。
在黑盒中探索方向
黑盒设计是一种可扩展性，它涉及到定制应用程序的用户配置，使该应用程序以对特定环境最有用的方式执行。当用这种方法扩展应用程序时，就不必查看原始的源代码了。
我们都使用过提供这种可扩展性的应用程序。例如，下面这两个应用程序：
Netscape 的插件功能
在用 Emacs Lisp 配置方面，Emacs 具有无限能力
近期，几乎每个新的应用程序都提供了某种程度的黑盒可扩展性。
如何识别一个配置脚本
在继续之前，让我尝试区别配置脚本与程序的其它输入之间的不同。不幸的是，这里真的没有什么明显的差别。程序接受的一组输入（及程序解释这些输入的方法）都可以而且应该视作一种语言。但是您应该了解配置脚本的几个显著特征。
与其它程序输入（每次使用应用程序时，都可以改变程序输入）不同，配置脚本趋向于更为稳定。这些脚本一般有一些缺省值，这些缺省值最初将由用户设置，并在很长一段时间内不会重置这些值。实际上，常在最初安装程序时设置这样的脚本。更改脚本的缺省值很可能会对程序在其它输入上的行为有重大影响。而且，因为永久 存储这些输入的值，所以在随后的程序调用中会检索它们。
明智地选择配置
现在，您可能询问的下一个问题是“何时向应用程序添加这种可扩展性是有意义的呢？”
答案并非是添加尽可能多的可扩展性。毕竟，这种方法的最终结果是：给定适当的脚本（类似于 �berapplikation），单个应用程序就会执行用户所需的每个任务。
可以论证，开发环境属于这一类，但是用户／开发人员所需的“脚本”可能会非常长且复杂。这个极端示例说明了对黑盒可扩展性的基本权衡 ― 应用程序提供的黑盒可扩展性越强，用户针对特定环境而配置它所必须执行的工作就越多。
通常，最好对应用程序确定的要求范围更窄一些，但仍可以通用，然后再针对更具体的环境。正如许多“极限编程（Extreme Programming）”小组所演示的那样，缩小项目的范围很可能还会使您真正地成功完成项目（而且还是准时的！）。