诊断 Java 代码:设计可扩展的应用程序,第 1 部分
 

2009-02-10 作者:Eric E. Allen 来源:IBM

 
本文内容包括:
诊断 Java 代码的这个部分和即将到来的几个部分中,Eric Allen 将他的讨论集中在判断一个新系统应该有多大的可扩展性、什么时候应用可扩展性是最佳的以及可扩展性与其它因素(特别是可测试性)的关系如何。在这第一篇文章中,他研究了能使一个软件系统具有可扩展性的各种方法以及每种形式的可扩展性各在什么样的环境中最有用。请在讨论论坛与作者和其他读者交流本文的心得。

随着对能应付日益增长的各种信息处理任务的软件系统需求的增长,找到能降低新的代码项目的生产成本的办法对软件公司是一种诱惑。最明显的办法之一是提高其它项目的代码的可重用程度。

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

  • 系统应该有多大的可扩展性?
  • 我能使系统具有多大的可扩展性?

如果原始系统被设计成可扩展的,那么重用代码是最佳的办法。否则,重用代码时碰到的困难可以容易地抵消任何已获得的生产率。但是,要设计成可扩展的,在软件设计中就要考虑各种各样的新问题。

我将在本文讨论一些办法,这些办法能使一个软件系统对将来的项目是可扩展的。

忠告

在进行任何努力之前,请让我澄清一下,我不是主张在所有情况或者甚至大多数情况下都为了可扩展性进行设计。有利于许多设计的可扩展性选择常常会妨碍其它需要考虑的因素,例如性能或可测试性。可测试性最好的系统常常也是最简单的系统,但可扩展性设计却常常会大大增加系统的复杂性。

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

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

在极端编程著作中,常常把可扩展性的收益和购买股票期权相比较:您早先购买了期权,因此在将来您可以容易地扩展系统。如果最终您行使了这一期权,则可以获利颇多。

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

下面,我们来看看术语 可扩展性的各种定义方式。当讨论程序的可扩展性时,我们所指的本质上有三种不同类型 ― 黑箱可扩展性和两种类型的 白箱可扩展性。 图 1说明了可扩展性类型的差别。

黑箱可扩展性

黑箱可扩展性是指这样一种方式:不直接扩展原始代码即可扩展程序。这通常通过使用配置语言或向导来完成,向导引导您完成对系统的扩展。

税务程序就是一个示例,这个程序包含一种配置语言,用于指定各种税务申报表。当政府发布新的税收申报表时,只需通过用配置语言说明新的税收申报表的结构即可扩展该系统。

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

  • 程序是专有的(非开放源代码)
  • 外界开发者在定制组件的功能性方面有一定程度的灵活性

支持用户定义脚本或宏的程序(如 Emacs、MS Office 等等)就是具有黑箱可扩展性的系统的示例。

白箱可扩展性

白箱可扩展性,相反地,是指可以通过修改或添加源代码对程序进行扩展的方式。我喜欢把白箱可扩展性区分为两个子类型: 开放箱 玻璃箱

开放箱可扩展性

当允许对原始源代码进行修改时,我称这个系统是开放箱可扩展的。当然,原则上说,这样的程序可以任意扩展,但不是所有的扩展难度都一样。

对开放箱可扩展性的研究主要涉及在必要的时候如何在给定的修改程序能力下使各种各样的扩展更容易。这种形式正是与开发小组在生产他们自己产品的下一版本时关系最大的可扩展性形式。

在有些情况下,这种类型的可扩展性也是想利用现有的开放源代码软件的开发者的兴趣所在。但以这种方式扩展开放源代码系统会碰到诸多问题。

最大的问题是当“官方”维护小组决定发布该软件的一个新版本时该怎么办。把他们的更改和您的更改熔合起来可能既困难又费时。 即使该系统是充分模块化的,足以使您已更改的实际代码也不冲突,要确保新代码预设的不变量未被您的更改破坏掉也是困难的(尽管如果代码带有单元测试,这个问题可以得到很大改善)。

玻璃箱可扩展性

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

因为上面所讨论的涉及改动外界维护的开放源代码代码的问题,所以在任何有必要的时候对这种代码只使用玻缡箱扩展是明智的。流行的、玻璃箱可扩展的系统的一个很棒的示例是 JUnit。每一个单元测试都可看作是原始代码基础的一个扩展。

图 1. 每种方式由代码对扩展者有多大的可访问性决定
图 1. 每种方式由代码对扩展者有多大的可访问性决定

关于箱的更多内容

这些不同类型的可扩展性各适用于一定的环境,其中的一些环境我已经谈到过。例如,在专有软件允许“外界”开发者对程序进行扩展(但不允许查看底层代码)的情况下,黑箱方案是合适的。

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

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

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

参考资料


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织