代码质量之可扩展性

 

可扩展性的动力——不断变化的用户需求

世界上不变的是变化，软件需求不会变化？不可能！一个系统是否拥抱变化是由它的可维护性和可扩展性决定的，软件环境的变化（可能是业务环境，运行环境）导致软件要进行改动才能满足人们对它的要求，这种系统本身适应变化的能力就是可扩展性。

 

可扩展性的设计忠告

可扩展性对系统的性能和复杂度都有影响，复杂度很高的项目很难维护，亦很难测试，我比较推崇可预见的、简单的扩展设计，愈简单愈好，避免前期大量的设计，对后期的无法预见的扩展，我们可以通过持续的重构来达到目标。所以，可扩展性不是一蹴而就的，是需要随着你对业务领域理解的深入而不断重构获得，一般三次可以达到比较理想的程度。

对于可扩展性的预见就像买股票一样，如果你买中了，你将会受益颇多，如果你没有买中，那么你的代码质量将面临臃肿和沉沦。这对你今后的维护和开发都造成不小的麻烦。

 

如何构建灵活的系统？

白箱可扩展性

开放箱式可扩展性

含义：原始源代码可以查看和修改。

手段：

• 直接修改代码，没有足够的注释，需要阅读一大片相关联的代码，才能理解其中的含义；代码风格混乱，完全不按标准出牌；码跟其他模块有牵连，需要其他模块修改，自己的工作才能进行。
• 直接修改代码，有足够的注释，良好的代码风格，容易阅读和理解，而且修改之处值局限在一个类或者一个模块中。

玻璃箱可扩展性

含义：可以查看源代码，但不能修改。

手段：

• 引入源代码工程和jar包，组合封装使用第三方的类库
• 引入源代码工程和jar包，利用继承，编写子类，在子类中添加新的业务逻辑

 

黑箱可扩展性

含义：扩展现有系统而不直接扩展其原始代码，源代码通常不可见，提供文档和约定。到了黑箱这一步，才算真正满足OCP原则。

手段：

• 修改配置文件，需重新读取配置文件使其生效。通常来说，这些配置文件保存着技术参数或者业务逻辑等等。
• 通过配置向导，比如使用什么数据库，使用什么语言环境，一般是在程序安装时候或者初始化配置时候将用户的选择保存在硬盘上，程序启动时会自动读取这些文件。
• 对象动态装配，使用java反射技术，在运行时期装载类（class.forName），比较有名的是spring中的依赖注入，它其实也要配置bean文件。
• 基于模块的运行时动态扩展，前面所说的都只是在比较细粒度上的技术扩展方式，而且都需要重新编译项目，才可能使新功能生效，都没有达到模块级别的扩展。OSGi可以实现模块级别的动态扩展，而且是运行时的。所谓运行时模块的动态扩展，就是说你可以将新开发的类和文件按照Bundle进行组织，然后直接扔到运行时环境下，这些功能就可以用了。Eclipse的插件体系结构就是以equinox（一个OSGi规范的实现）为核心构建的。
• 基于平台，让开发人员自行扩展，平台和框架通常定义了一些Hotspot（热点），在这些点上，可以进行扩展，比如window提供数千个API供应用程序调用，还有firefox、chrome的插件，以及各种应用平台（facebook、taobao），它们大多数都是通过中间语言进行扩展，具体的技术细节还不太清楚。