写可复用的C/C++代码

在现有软件的新版本开发的过程中，老板最希望看到的是能够在最大限度复用现有代码的情况下扩展软件功能从而满足新的需求。软件架构从框架上决定了代码复用的程度。只有设计良好的应用框架，才可能最大限度的保证代码的复用；对于面向对象方法而言，类设计对于代码复用的重要性自然不必说了。本文试图从软件设计的角度来考察代码级的复用问题。

保证软件可服用的一个最高原则，也是最简单的办法，就是从架构、模块、类等层次上采用各种设计模式达到各自层次上的低耦合的目的。

  框架要反映出问题的真实面目

  开发软件的终极目的是为了解决实际应用问题，应用框架是应用逻辑的高度抽象，从不同的视角观察应用问题，会得到不同的解决方案，从而得到不同的抽象结果，也就是不同的应用框架。正因为应用框架只是应用问题从某个视角”观察出来”的一个抽象，因此，它不可避免的与应用问题存在或多或少的的冲突，这些不一致的地方最终会为软件设计工作带来麻烦。因为这些冲突导致我们在设计和编码过程中，会不断遇到各种“意外”的情况,我们将不得不努力以曲线救国的方式来消除这些冲突。这种额外的消除冲突的工作，对于软件开发工作很不利，有时甚至带来性能问题。

如果把理想的应用框架比作一幅优雅的风景画，那么这些冲突就是画上比较显眼的令人不舒服的污垢。举个磨具的例子，要生产某个产品，可以先按照产品规划做一个磨具，再按照磨具来制造出最终产品;这里规划的产品是应用问题，磨具是应用框架，生产出来的产品是最终软件；如果磨具不是你想要的，生产出来的产品肯定跟规划的产品有很大差别。这里想说的是，一个好的应用框架应该尽可能真实的反映出应用问题的真实面目，至少应能真实地反映出我们关注的方面。

 试想，一个框架在满足现有需求时尚且需要修补各种“意外”情况，当它面临将来未知的新需求时，又如何能很好的适应呢，不能适应又谈什么复用呢？良好的架构是复用的基础。

 隔离应用框架与业务模块

  如果应用框架与业务模块混杂在一起，形成一个高度耦合的状况，那么在软件的升级开发过程中，应用框架与业务模块都需要变化，甚至完全不可用，而且新产生的系统中，框架和业务模块都是未经过验证的。如果二者各自独立，那么可能保留早期版本的框架不变，只是变化业务模块，或者新增加一些新的业务模块，而框架已经是经过验证的，从而实现了框架的复用。最理想的情况是，新增加一些业务功能，不用修改框架和现有业务模块，只需要增加一个新的业务模块。

分离耦合

由于应用问题是复杂的，系统又往往是一个有机的整体，因此很难做到业务模块之间绝对的绝缘。既然各个业务模块做不到老死不相往来，那么模块之间可能存在依赖或者关联的关系。我们应该如何处理这些耦合呢？绝对绝缘是做不到，分离出存在耦合的部分，却是可以做到的。想象一下，不断的分离出耦合的部分，大模块中分离出一个小模块，用于处理模块之间的交互，小模块又分离出耦合的部分，反复几次，理论上应该可以找到模块之间真正需要交互的部分。如果将来某个模块变化了，那么只会影响到其它模块的真正需要变化的很小的一部分存在耦合的部分。也就是说，在未来的软件升级开发时，会最大程度的复用现有版本的成果。

发表于 @ 2007年05月09日 23:39:00|评论(loading...)|编辑