漫谈程序架构与设计模式

      如果把程序架构想象成为一颗大型圆球状的树的话，一个优良程序的成功秘诀，按照个人理解和二年来在编程江湖上的行走的经验，我想很多时候，其在架构上采用了“在枝叶处确定细节，而在核心区假设或者假定最少”的构建策略。并且在实际操刀编码时，对问题域的固定部分，用语言的硬编码，以将挡之；对问题域的变化部分，用语言的变量，以兵淹之。我想，作个大胆的预言，符合此道的程序，就可以获得和“宇宙”一样的永生了！！

   举个例子，来演示一下，自己的这个观点。例如，对于

int  add(int a,int b)

{

  return a + b;

}

　　对于这个程序片断来讲，它的固定部分－－加法逻辑，就用不可变的代码写死之，即那个+加号；它的变化部分－－加数、被加数以及总和，就用可变的变量，允许其在整个程序的生命周期中任意变化。可以看到，这个加法逻辑可以做到适用性极广。虽然这个例子比较简单些，但是足可以看出符合前面所叙说设计原则的程序是具有很强的生命力的。另外，在这个演示例子中，虽然对“在枝叶处确定其细节，在核心区假设最少”的观点映照比较少，但也可以看到其模糊的影子，在调用这个程序片断的地方，就是确定加数和被加数细节的枝叶，假设外界只会给予加数和被加数的片断就是假设最少的核心区　：）
　　

　预想“在枝叶处确定其细节，在核心区假设最少”这样的观点所对应现实项目的映像，由于我参加的大型项目经验也不是很多，不能以身体力行的作品来演绎，但是，我们可以用这个观点去剖析经典的程序结构，你可能会发现优良的程序设计中都或多或少地印证了这个观点的影子。例如，冯诺依曼计算机“存储执行”的机器模型，我们看到，在模型的枝叶处，各个具体的应用程序，用机器环境所提供的逻辑操作、内存操作、文件操作、数据库操作、网络操作、图像操作、外设操作，形成自己各有特色的服务行为，但是，对于"存储执行"模型来讲，核心层实际上只是假设“被存储的指令需要被执行”这样一个概念，一个简单到极至的假设，而且具有很稳定性的简单假设或假定。通过这样一个枝叶与核心区的计算结构，我们看到了琳琅满目应用程序和存储执行模型无限的扩展能力。希望，能够解释的了自己提出的观点，再复杂的例子会占用很多的篇幅，对于概念性了解这个观点也无益。其实，在实际中我们解决问题只要秉承这样的思考方向，我想我们也能作出不错的程序设计的。

　但是，如何来做到具有这样良好结构的程序设计呢？是从宇宙的尽头看到地球，还是从地球看到宇宙的尽头呢？即是从核心区细化到枝叶，还是从枝叶抽象到核心区呢？我想，两条路都是可以走的！其中，每一个过程不过是另外一个过程的反演，但是，两个方向的过程体现出来的对思考者具有能力的要求是不一样的。一条路是近似平民化的柏油马路，不需要具有超绝一流的思考力，而另外一条路，只有能进入计算机“名人堂”的人，具有深厚数学背景知识、厚积薄发的人，才能为之吧。。。。！对于，我自己呢？！处于这两者之间的那个地带，呵呵，虽然作为操刀的评论者，其实自己也不敢居于这两个座位的任何一个！一个比较恰当的比喻是，我只是一个能够看到前面风景如此秀丽，但是，却无份拥有之的看客。不过，内心的渴望是：前行的每一步都有可能接近神话与美丽！

　抽象细节到细节所共同拥有的基座，在我看来是稍微容易的过程；而首先，建立其核心区，再细化到枝叶，在我看来是一个比较难、荆棘丛生的过程。例如，一些经典的模型和架构理论。图灵机到现代计算机、冯诺伊曼“存储执行”模型到多道程序的执行、MVC框架到各种Web程序。每一个列举的场景，都体现了极其稳定的结构特质和特征，拥有共同的核心区，并且我们在其“子类化”的应用中都能够发现、看到它的骨骼。我们如果对提出的几种场景过程进行反演，推导其逆过程，都可以看到一个从细节到共同持有因子的历程，一个动若狡兔、静若处子的架构。

　　我们后来人进行正推或者是反推这些过程，推演起来要容易多了，呵呵！虽然是重复咀嚼前人的“非”残羹冷炙，这些概念可是我们计算机界璀璨的明珠的，偶不敢薄之，我们依然能够体会到一种事后诸葛亮的思考快感。但是，在这里我们一贯“谦逊”的程序员，应该对我们的前辈致以崇高的敬意。在他们真正开始创造这些过程的时候，每一个细节都是举步维艰的，都是经过千百次的寻找和锤炼，才能提炼出来的真知。不过，劳动是快乐的，尤其是得到劳动果实的时候，就象我们即使在重复咀嚼计算机界的前辈创造的真金白银的时候，我们还是都会感到一种快乐，何况是亲自操刀、鬼斧神工下呢？！

　闲谈一点对计算机编程的看法，奇文共欣赏，疑义相以析！