快速适应需求变化的软件复用

软件复用本质是为了快速适应不断变化的需求（adapt to changing needs ），两者目标是一致的，但是当我们过于注重软件复用（如组件复用component reuse又译构件复用）时，千万需要牢记：快速适应不断变化的需求是根本目的，它的重要性要重于组件复用技术本身。本文试图阐述两者概念比较以及时下流行的组件复用技术概要。

适应需求变化

现如今是一个计划赶不上变化的时代，企业竞争力逐渐表现在企业适应变化能力的竞争，谁能更快适应市场的变化，谁就能够在竞争中胜出，这种快速适应能力如果靠“人民战争”无疑是不现实的，软件可以帮助我们来适应这种快速变化。

谈到这里，稍微再说明一下国人软件教育的误区，不错，软件曾经是科学计算的工具，因此，我们非常注重软件的算法和数据结构，甚至将之作为数学的衍生物，但是，现如今已经成为一种帮助我们快速响应变化的有力工具，如果我们的教育背景中只有算法和数据结构，能够编制出应付快速变化的软件吗？很显然，他们是风马牛不相及，由此可见国人软件概念和软件教育的落后性，在这样的软件认识背景下，固然设计模式的崇高位置得不到确立，软件设计被抛弃在脑后，编制出的大多数企业软件系统根本不具备应付变化的能力，程序员拒绝频繁更改程序，甚至借助技术原因阻扰软件的频繁更改，这种软件程序员和软件用户之间的矛盾可以称为miscommunication， miscommunication是导致软件系统的失败一个重要原因。

国内早就有著名言论：“不上ERP等死；上了ERP找死”，如果你的企业不上ERP，那么你的企业就不能借助软件应付快速的市场等环境变化，那么必然会被淘汰；但是，如果上了一个不注重“适应需求变化”的ERP软件系统，那就是企业被僵化的ERP软件框死，丧失了使用ERP的根本目的。

适应需求变化则成为现代软件系统一个孜孜不倦的追求目标，那么如何实现呢？

原则：给予人们可以裁剪他们系统的能力应适应需求变化，建立一个适应需求变化的系统，允许系统在一系列小的、可控制的步骤上进行改变。　　

组件诞生

将不变的通用的东西抽象出来，以达到在不同项目中重用复用，将我们有限的精力集中在项目具体变化和特点上。当然这些抽象复用的东西之间彼此必须是松耦合，这样才能根据需求挑选组合。

让我们先回顾一下软件的发展史，软件开发的发展史实际是一部我们思维不断抽象拔高的发展过程，这种抽象概念非常类似于建模的思考方式：概要贴切地描述事物，忽视次要的细节。抽象体现在软件开发上就是每个具体项目需要完成的代码行数量越来越少。

从1970到1980这段时间，软件开发从机器语言到汇编语言。进而发展到高级语言，甚至一些CASE工具，面向功能编程发展到面向对象编程，功能模块重用细化到类的重用，类的重用是最初是通过设计模式实现的。

进入90年代中期，诞生了基于组件的开发模式（CBD：component based development），CBD将抽象概念带往了一个新的方向，与减少代码数量相反，CBD将功能各个方面细化分离到不同的、相互隔离层中，如表现层、业务逻辑层、持久层、安全层以及核心层等，并且可以管理这些组件之间的依赖关系，通过这种分离，我们可以提纯细化组件功能，进而产生可以重用的框架，如Struts框架可以重用在大部分应用系统的表现层中，，Struts+JdonFramework+Hibernate是一个框架组合，代表一种架构设计，这种架构设计其实可以重用在大部分应用系统，这种重用我称之为架构级别重用。

组件复用

软件组件(Software components)是软件提供业务或技术功能的基本单元或元素，这些单元可以独立地被部署、他们可以自我管理并且被虚拟部署到网络的任何地方，业务组件（(Business components)执行业务逻辑、遵循一定的业务规则并且管理相应的数据（数据库操作称为manage corporate data）；而技术组件(Technical components)则提供相应的平台以便业务组件可以依赖其上运行，例如权限、组件管理等。

JdonFramework/Spring都属于一种技术组件框架，而我们具体项目的业务层代码如果能够提炼可以复用，则是业务组件；JdonFramework/Spring则都提供了业务组件赖于运行的一些核心底层机制，特别是组件的管理，如组件的创建、组件的获得、组件的资源管理、组件的消亡等生命周期支持，所以，我们可以在JdonFramework/Spring中加入自己的业务组件，当然，JdonFramework还提供了Session等状态管理的支持功能，为业务组件提供了更广阔的生命周期支持。

组件复用技术以前是停留在编译前期，也就是说：我们在编程时，导入所需要的其他组件Jar包，然后混同我们的项目编译部署，但是这需要通过专业技术人员实现，很显然是不能适应原则中第一句：给予人们可以裁剪他们系统的能力应适应需求变化，这里的“人们”应该是指软件最终用户，应该给予用户自己改变系统的能力，也就是说：需要提供软件系统运行时能够动态改变自身的能力。

组件复用技术以前停留在软件编译阶段，现在则更靠前，必须在软件运行阶段，当然对技术要求相当高，需要语言支持RTTI（简单又神秘的Class.forName发挥作用了），这在"Evolution, Architecture, and Metamorphosis"一文中被认为是Metamorphosis，现在由于AOP技术出现，AOP有一种动态Weaving技术，实际就是在软件运行时实现动态拦截，这样给予终端用户更大的改变系统能力，他们基本可以以动态插拔的概念实现多个组件的组合运行。在"AOP vs Decorator"一文中，我把编译阶段的组件组合方式（我更愿意称为静态组合）和运行时组合等两种处理方式，合并称为过滤器模式，如果你希望采取组件可插拔式的复用，就可以使用过滤器模式。