面向各维度的软件复用

复用！使我们软件工作者梦寐以求的目标。所谓复用，就是在不改变原有代码的情况下，重复使用原有代码。面向对象（OO）技术的三个基本特点都是为了复用。

1. 封装。这个本就是为了复用。是对复杂数据结构的复用。事实上，封装并不是只有在OO在才出现的。
2. 继承。是对基类代码的复用。派生类在不改变基类的情况下，复用了基类的代码。
3. 多态。是对调用基类的代码的复用。调用者可以在不改变代码的情况下，使用到派生类的新特性。

不过今天我们不是只谈这方面的复用。

软件按照各种变更需求，我们可以看出几个维度对软件的复用需求。

1. 软件需求变更。软件在需求变更的情况下，原有业务模块会发生变更。在这种情况下，属于要求对原有系统的复用。这是我们最经常说的。
2. 软件版本升级。软件经过一段时间后，原有系统会进行升级处理。在这种情况下，属于要求对就版本系统的复用。这种复用经常被人忽略。或者说其复用难度很高，很少有人能做到。
3. 软件系统整合。一个非常重要的需求，就是在系统整合过程中，需要复用企业中已经存在的软件。虽然说，原有软件开发商并不一定要考虑这个问题。不过，复用可以带来明显的经济价值，其成本低的诱惑力，致使企业必然走这条道路。

基于这三个维度，我们都提出了对软件复用的要求。这也是软件发展的三个维度。如下图：

你可能已经注意到了，大家经常提到的面向对象技术没有被我显式列入图中。不过这些技术都是可以以OO为基础的。特别式组件技术。

在需求变更发生的时候，对已有二进制模块的复用是最有效的复用。因此我这里推荐使用插件技术。插件技术有微内核和巨内核两种扩展方式。个人推荐第二种。使用中具体情况具体分析。使用插件技术，可以直接在原有系统的扩展点上，通过增加的插件来实现业务的变化。这样，原有其他系统都不需要经过大量测试。且效率也是非常高的。

这里提到的测试成本是非常重要的概念。从物理模块上讲，任何已变化的模块，都是不可信任－－即必须经过测试的。如果能完全复用，那么这些没有变化的部分的功能的测试工作，将变得非常简化。

软件版本之间的复用，一般都是指高版本复用低版本的模块。细化一下，可以分为业务实体复用，界面功能元素复用，业务模块复用。这个概念的复用，由于介入了业务，所以导致其方法和经验不能在全世界范围公用。这也是程序员最头疼的地方。不过，都不好做也是好事，这样大家都不提这件事了。至少在设计新系统的时候，很少考虑复用旧系统的模块，或者如何让将来的系统复用现在的新模块。没有人会责怪你没有考虑这点。

好在，这个问题越来越被重视。这里面一个是早就提出的组件技术，一个是平台技术。其实这两者在这里是一样的。平台技术也正是基于业务的组件。将两者合在一起，就是业务组件技术。POJO技术（pure old java object or plain ordinary java object）就是针对此类复用而提出的一种纯业务概念，这也是让业务实体能够在后续版本直接复用的概念。让业务对象，不需要考虑系统环境，而只关系业务本身的实现。因为在后续版本中，基本业务的差别是不大的。所以其复用的可能性会非常大。业务组件的编写，对设计者的要求非常高，需要在设计的时候将组件和环境的关系隔离开，以方便后续版本的复用。

组件概念提出很长时间了，但是都没有很好的实现，与其对设计的要求很高很相关。关键还在于我们在对业务理解的精深以及设计中对组件概念的把握。

系统整合中的最大问题，在于已存系统很可能并没有考虑与其他系统的接口。这种情况下，二进制的复用难道就会变得很高。在这种方式的应用中，最基本的就是消息技术。将对已存系统的调用，封装成各种消息，发送给已存系统。这些消息可以简单的是Windows消息，也可以是WebService消息。有些公司已经钻研透Java的实现底层，可以直接将消息发送给Java虚拟机。请注意这里的消息的概念很泛化，泛指命令的组成形式。

总之，各种维度方向的复用，最基本的要求就是设计上的考虑。与其后续的考虑，不如新做的时候就在设计上进行考虑。复用，要把它作为心中紧绷的弦，才可能真正做出能复用且可被复用的软件出来。