Mach de Bagua    

翻箱底，几篇很久以前没写完的笔记。。。

看过金庸的武侠小说《笑傲江湖》么？里面有个华山派，华山派有剑宗和气宗之争。剑宗讲究的是招式，而气宗推崇内功。软件的世界，也是一个江湖，行走江湖就是不断出手的过程。很有趣的是，武术的招式和内功在软件的位面里有着投影。。。

什么是软件的内功？对编程语言的理解、对算法/业务流程的理解可以被看作内功。例如说，我常被新工程师问到的一个C的问题是：请教把"2046"这个字符串数组转换成整数应该怎么办？－－好吧我的答案就是一句话，"函数atoi()，自己去查MSDN"。知道不知道一个功能函数，无关个人能力，只是他有没有遇到过的问题，更多的是经验的积累加上一点本能，很符合内功的一些特点：需要通过修炼（做项目)获得，通常年龄越大内功越高。近年来开始有人试图在软件设计方面归纳出一些内功心法，就是所谓的DDD(Domain Driven Design)，这里面的domain指的是业务领域，对它的建模叫领域模型。这个话题以后再谈。

再说招式。早先学计算机的人都知道一个等式，"算法＋数据结构＝程序"。这个等式在早期程序大多开发用来坐科学计算的时候是适用的，但是，一个软件，除了算法和数据结构，就没有其它东西了么？那个加号是什么？其实是值得琢磨的东西。而且这一点在面向对象的时代显得更突出，就是对象之间的关系用什么来描述？即使在非对象的编程里面，一样也有模块的概念，最小粒度的软件模块之间关系同样是值得关注的话题。

1995年，Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides这四个人（常被称为四人帮，在英文里就是GoF）写了一本著名的书《Design Patterns: Elements of Reusable Software》，直接了当地说，软件对象之间的关系可以用建筑学的名词design pattern（设计模式）来概括，而且列出了23种常见设计模式。这几个人厉害就厉害在，后来其它人想了又想，却不太能想出更多的设计模式，就是说天下武功都不出这23招，洞察力果然了得。

值得指出的是，说到四人帮的模式的时候，一定要指名带姓说"设计模式"，光说模式是不精确的，因为设计模式其实是软件设计里最低的一层，再低就低到软件实现里去了。在设计模式之上，还有所谓的"软件模式"，例如著名的MVC模型，同样不是在这里讨论的话题。

往往会有这样的情况，一个工程师可能用过某个设计模式，而其实他并没有看过四人帮的书。这很好理解，设计模式本来就是软件实践的概括。但一个工程师23个设计模式都用过的，倒也不多，从设计模式的书里面往往可以得到一些启发。这就是学习设计模式的意义了：总结历史，学习经验。

下面会随机挑一些设计模式来做分析。有两点要说明：
1) 我认为设计模式的实践不限于面向对象设计（OOD），所以有可能举一些非面向对象的例子。
2) 为了说明类或者软件模块之间的关系，使用了UML标识图。UML是一种用来标识对象和对象间关系的图释法，相当直观，看懂它不比看懂通用地图的图释难多少。用UML结合Rational公司的软件Rose来做设计并自动生成代码当然要仔细了解使用细节，但只是为了看懂UML图而去看那些砖头一样厚的书是浪费时间。UML仅仅是工具而已。

在这里列出四人帮归纳的23种模式，他们把它们按目的分成了三个组，按作用对象分了两个组，结果就是这样的一个矩阵。其中Adapter模式即可以作用于类，也可以作用于对象，所以矩阵里面有24个项目。

在继续深入之前，强调一下，设计模式是软件设计中的重要一环，但是领域模型也很重要，很多时候都要比设计模式更难做好，相比之下设计模式要简单一点。。。个人观点。这么说我是华山气宗的观点了，嘿嘿，要和君子剑岳不群岳先生划清界限啊。。。

未完待续。