比较软件架构、设计模式、应用框架

[转]比较软件架构、设计模式、应用框架 
 
鄙人不才，在此斗胆谈谈我对这几个概念的一些理解！据我所知，这些概念远没有被完全统一起来，不同的人有不同的理解，所以你不能像在中学里学习数学或物理（这些书中的概念和定律都是早有定论，完全是系统化的，前后决不会自相矛盾）那样，但学软件工程，我觉得有时更像在学习哲学，而且是诸子百家争鸣时期的哲学，有些观点会有一些冲突，软件工程现在也是百家争鸣时期，很多东西没有盖棺定论，现阶段还没能有把它完全的系统化和统一化。

因此下面我仅表述我在学习和工作实践中对设计模式、架构和框架等这些重要概念的理解！

设计模式是对某一类典型问题的通用解法，它强调某一个局部的合理性。相对来说，它是微观的，是老百姓的需要考虑的一些事情，是程序员或某一子模块设计师的工作任务。

而软件架构更关注于整体，它需要更多地从宏观上、从整体去考虑问题，因此，系统构架师需要对整体系统的合理性担负负责。

但我个人认为，目前我们对架构有一个理解上的误区，认为架构就是系统的骨架，我觉得这似乎不太对头。因为其实框架才是系统的骨架，好比建房子，现在通用的方法总是先搭个稳定而结实的房屋骨架出来，这就是楼房的框架（framework），也是房屋的主体，然后再是其它的修饰，如安装窗户，中间隔出多个小房间来等等。软件也是如此，因为很多程序的主体可能都是类似的，所以把这些东西抽象出来，设计并提供给程序员一个可重复利用的程序主体，这将不仅极大减轻程序员的负担，减少开发成本，而且我们的很多程序也就因此有了很好的一致性（不至于你的程序一个花样，它的又是另一个花样，五花八门，那就太乱了），实际这就是程序的框架，如MFC就是最为成功的框架了（其实MFC是一个类库总称，它里面的如MDI、SDI，以及各种AppWizard就是为你生成各种不同类型的程序框架），然后程序员的工作任务实际就是在此基础上扩展子模块子函数之类的事情。

那到底何谓架构呢? 能不能说得通俗、透白、直接一些，我觉得我曾经看过的一本书里有一句话概括得非常好，这句话是：“架构不是所有的事情，但它确实关乎每一件事情”。

怎么理解这句话呢？其实它的意思很简单，我理解就是架构不关心所有的细节，但它应该关心每一个重要的细节（会影响到整体的系统）。因此架构不是程序框架，不是骨架。而是所有重要的事情，例如：我们的系统需不需要利用一个现有的框架；选择一个什么样的框架，或有没有必要开发出一个更适合自己当前系统的框架；又如何在此框架上做扩展等等。换句话说，架构是关注各个子模块如何组织及开发，又如何交互并组成我们最终需要的系统，它关注的是这些元素之间的组织关系，以及如何交互，才是最符合当前的这个系统的实际情况和最大利益。

举个例子来说吧！不知道恰不恰当，美国世贸大楼100多层，主体框架是钢结构，倍棒，没得说！美国人为此曾骄傲了多少年！也许在它轻易倒掉之前，没人怀疑它的主体框架设计有问题，但事实令他们很惭愧！最后调查原因发现，大楼倒掉的原因并不是由于飞机的撞击，而是由于飞机撞击后引起的大火，最后导致钢主体软化，承受不了大楼的重量而倒塌的，所以说，当初的总体设计师也许考虑了大风、地震等灾难，但它却没有考虑到大火会引起钢材的软化，结果却酿成了世纪大灾难！所以，归结到底，这灾难其实是架构师的责任，他在设计时必须要考虑到会关乎到系统的每一件重要的事情，哪怕这件事很细微。

最后补充一点，前面也提到，我们的程序不一定有框架，但一定会有架构（也许或多或少，或好或坏）。不选择框架的原因有很多，如我这个系统的某个子系统打算用VC编写，这个子系统的特点是：它是整个系统的核心构成部分，也许代码量不是很大，但它的运行效率却关乎到整体的性能，它可能会构成系统的瓶颈，因此设计师也许会考虑不用MFC，因为MFC内核太庞大了，这个子系统程序根本用不到MFC提供的那么多的功能，因为很多MFC里面很多对其它程序有用的功能在这里就可能会是累赘，是系统的负担，因此架构师可以考虑自行开发一个适合自己的小框架（假如项目资源允许的话）、或者干脆无框架，完全用平坦式的C函数累积成一个性能极高的核心程序，也未必就不是一个好的架构。到底做出何种选择，设计何种方案，每种方案的优缺点，系统的关键点在什么地方，这就是系统架构师的工作范畴！它需要关心影响到系统的每一件重要的事情，而不仅仅是框架！

总结陈述：“设计模式”是某个局部；“框架”是程序的骨架；“架构”是局部如何组织为整体！

作者：王胜祥