从模式说起
“模式”这个词进入中国软件开发者的视野，是从《设计模式》[2]一书开始的。2000年9月，中国的软件开发图书市场还远不如今天繁荣，相信这本书给绝大多数人的都是一种耳目一新的感觉。突然之间看到如此之多精致优雅的解决方案，足以令长期苦苦探索设计之路的开发者们“漫卷诗书喜欲狂”了。
在那个时候，我也是模式的痴迷者之一。还记得2001年，我和朋友的通信中多次表现出这样的痴迷。下面是我2001年10月给朋友Windy的一封信：
对“面向模式的设计”的开悟，在十三陵。
站在长陵的绫恩殿，宏大的建筑，给我一种鹈鹕灌顶的感悟。那天John
Vlissides说，Christopher Alexander曾经说中国的建筑给了他很多灵感。今天，我想我抓到了一点大师的感触。
繁复的构造，精巧的设计，却能天衣无缝的组成如此完美的建筑。无疑这是设计的成功。仔细观察之下，发现对于各种各样的建筑，其组成元件——棂椽梁柱——却都是毫无二致。这是多么高的复用程度！这体现了多么成熟的设计体系！
在公路边，一些建筑工人在建造一组仿古的房屋。朝代更替，光阴流逝，但工人们仍然能够完美的仿造四百年前的建筑。因为他们一代代流传着精确而形象的模式语言。
尽管我看Shalloway的Design Patterns
Explained已经有一段时间，在今天，我终于知道为什么他如此钟情于Alexander的建筑模式了。
可惜，由于缺乏一种文化的积淀，《设计模式》的读者们（包括我在内）都患上了消化不良。我大胆估计，《设计模式》在中国软件业造成的负面效果绝不少于其正面效果。Alan
Shalloway曾经说，“模式”并不仅仅限于“设计”，甚至“设计”二字正是导致最多误会的根源[3]；John
Vlissides在他的Pattern Hatching中列举了对模式的“十大误解”，其中提到“模式并不仅仅是一种解决方案”[4]。但是，有多少人知道，为什么？
正是因为缺乏必要的背景知识，中国开发者对模式的了解往往是片面的甚至是错误的。如果把模式仅仅视为一种解决方案、或者一种反复出现的情况的总结，那么它顶多只对软件开发有一定的帮助或者指导意义；如果只把模式作为预先（up-front）设计的方案，它甚至会导致过分工程（over-engineering）。总而言之，模式顶多只能算一种“好东西”，至于“永恒之道”这种溢美之词，即使最钟情于模式如我，也是不敢出口的。
建筑的永恒之道
在面对一门有数十年思想基础和十余年发展历史的学科时，我们必须承认自己的浅薄，我们必须不断学习。同时，我们必须有自己的思想。苏格拉底说：“我们无知，所以我们有智慧。”
为了真正理解GoF的思想，为了真正理解模式的思想，我们有必要先深入其思想基础。于是，我翻开了手上的书。于是，我看到了与我以往的理解完全不同的知识，我看到了一个崭新的世界。
记得上面的一个问题吗？“模式并不仅仅是一个解决方案”。这句话是什么意思？请看下面这段话：
模式系统形成了一种语言。
从数学观点看，最简单的语言是一个包括两个系列的系统：
1. 一系列要素或符号。
2. 组合这些符号的一系列规则。
然而，模式既是要素，也是规则，所以规则和要素不可分。模式就是要素。每一模式也是一个规则，它描述了本身也是其他模式的要素的可能的排列。
于是豁然开朗。从最初的定义开始，模式就不仅仅是解决方案，而是一种完整的语言。作为解决方案，模式构成了语言的要素；而作为语言规则时，模式的意义同样重要，甚至更加重要。而这个方面常常被《设计模式》的读者们忽略了。
仅从书名就可以看出，作者把模式当成“建筑的永恒之道”——这种说法是否有点太不谦虚了？请看作者的解释：
有人已告诉我们，优秀的建筑与低劣的建筑，优秀的城市与低劣的城市之间没有客观的差别。
其实，建筑、城市的好坏之别是一个客观的问题……不过易于理解，为什么人们如此坚信好劣建筑之别没有单一坚实的基础。
这是因为产生这种差别的独特的中心特质无法命名。（为什么这种特质无法命名？）
把（这种）无名特质想象为一点，我们试的每个词作为一个椭圆。每个椭圆包括这点，但每个椭圆也包括许多远离此点的其他的意义。
因为每个词总是像这样的一个椭圆，所以每个词对于作为点的特质来说，总是太空泛，太不明确，范围太大。没有一个词可以表达无名特质，因为特质太特殊，词太广泛了。但是，它是存在于任何人、任何东西之中的最重要的特质。[6]
很明显，这里所说的“好”的建筑和“差”的建筑，都不包含结构有缺陷的“豆腐渣工程”。在结构工程学能够保证结构的稳固、健壮之后，建筑师们想到的便是如何让建筑真正满足人的需要。在书中，作者多次表示，尽管现代建筑有极其优秀的结构，却缺乏优秀的设计，导致大量的建筑违背人的本性。
我们已经说到了“人的本性”。那么，建筑中“人的本性”在哪里？它就在数千年流传的模式语言中。一个特定的模式，在特定的场景下，辅以特定的相关模式，它就是符合人的本性的，因为模式是“允许其自身内力自我疏解”的，而模式语言又是有活力、能够自我发展的。所以，基于模式设计、设计反向影响模式语言，这样的过程正是“建筑的永恒之道”。
在此有些个人见解：我们已经太习惯于IT图书那种填鸭式的教学方法了，我们已经太习惯于“一本入门应用、一本进阶原理、一本参考资料”的读书方式了。再说一次，当我们面对Christopher
Alexander这些人文气息浓厚的技术书籍时，我们必须承认自己的浅薄和无知，我们必须用自己的智慧来思考。中国人最擅长逻辑思维，是以中国人也最容易被一些似乎有意义的词汇蒙蔽双眼而陷入逻辑先验不能自拔。当《建筑的永恒之道》在一开始就告诉你“这种中心特质”无法命名的时候，你是不是很不能习惯？继续读下去，让你快要生锈的大脑运转起来吧。
回到我们的模式
我这里所说的“我们的模式”，是指“软件开发中的模式”。介绍了这么多建筑学中的模式，对于软件开发者有什么意义吗？或者说得更直白一些，模式会是“软件的永恒之道”吗？对此，我没有答案，只有讨论。不过我相信，没有人能够知道真理，有讨论、有思考，我们就能离真理更近一些。
由于此书成于1979年，作者又是一位建筑学家，书中自然也无法给出关于软件开发的答案，仍然只能靠读者自己去思考。读完两遍之后，我的心得大约有以下几点：
----和建筑结构一样，软件中亦有诸多的“内力”。和建筑设计一样，软件设计也应该努力疏解系统中的内力，使系统趋于稳定、有生气。一切的软件设计都应该由此出发。
----任何系统都需要有变化，任何系统都会走向死亡。作为设计者，应该拥抱变化、利用变化，而不是逃避变化。
----好的软件只能“产生”而不能“创造”，我们所能做的只是用一个相对好的过程，尽量使软件朝向好的方向发展。从这个角度来说，开发的迭代周期越短越好。
----软件的工业化使软件僵死、失去“无名特质”、谬误百出、脱离现实。通过规程、制度来控制，只会使系统内力无从疏解，最终走向崩溃
模式到底是不是软件的永恒之道？最终，我还是无法给出一个答案。但是，我相信，充分理解模式语言，充分理解模式语言和设计的关系，会帮助我们提高设计能力，也会帮助我们丰富模式语言。
|