Design Pattern On Road

序

这篇《设计模式之路》是看完四人帮的《design pattern》之后的感悟。《设计模式》重剑无锋，大巧不工。即使有很好的编程基础，很高的英语阅读水平，也未必能窥知全貌。笔者试图将《设计模式》演绎为通俗易懂的白话，简单生动的故事。在闲暇时光，重温旧知，也是一件惬意的事情。

为什么取名为on road？是因为笔者一直在探求知识的路上，而这条路永无终止！

顺便说一句，想不看《设计模式》，直接看了本文就想弄懂什么是设计模式的，有点儿不切实际。本文源于经典，不能超越经典，必须有点儿基础再来看看。

另外，《设计模式》这本书也需要懂一些UML的知识，如果没有的话，请在百度或者谷歌一些UML的基本知识，至少需要知道什么是依赖、继承、组合、聚合之类的概念。

起

《设计模式》这本书起源于一个文本编辑器的开发案例。我相信这四个老贼选取这个案例要么是他们在开发过程中真正的痛苦过；要么就是非常鸡贼的，有远见的，刻意的选取。我相信前者的原因居多。科学来源于实践，能在开篇中就将lexi编辑器举出实例，且映射了8个设计模式的案例一一列举。没有经历过（这个编辑器的开发过程），让人很难相信。

一个文本编辑器，设计的8中设计模式如下：

组合模式

策略模式

修饰器模式

抽象工厂模式

工厂模式

桥接模式

命令模式

迭代器模式

• 组合模式
  

组合模式在Lexi编辑器这个case中出场的情形最普通。就是设计者（使用者、开发者，随便怎么称呼吧）需要对编辑器中的字符、文字、图片、行、列等“对象”，进行统一的处理，不希望这些“散乱”的对象有不同的行为和属性。就设计了一个名字叫做Glyph的抽象类，这些“对象”就被实例化自Glyph类的子类。

这里不讨论为什么统一了行为就是合理的（本人从来相信“有钱难买我喜欢”，但要证明这个统一行为的合理性，要浪费我不少字，我一向又懒得写字），姑且我们认为“存在即合理”或“四个老家伙”“喜欢这样的统一性”。简单说下组合模式的使用特性：

1. 要组合的类，必须具有统一的行为接口，比如上文的字符、文字，都有size，都能自我draw（渲染），都能知道自己在文档中的位置（postion）。

2. 要组合的类，必须能够递归组合，即一个Glyph必须能包含若干个子Glyph类得对象，而且一个Glyph可以有一个父类Glyph对象。

3. 要组合的类，根据第3点，能够像一棵树一样，从不同的node之间进行对象的游历（注意，我说游历，这里不使用“遍历”，为的是和迭代器模式区分开）。游历的方式包括“父类.getChildren()”和“子类.getParent()”之类的明显的表示方法。

组合模式，要区分于UML中的类或对象之间的“组合”关系。UML中的“组合”的关系，是描述两个类之间的关系的，而组合模式是描述具有上述三点特征的一组类之间的“组合”或者“聚合”的关系的。

[2012-07-11 to be continued...]