一枝看上去很美的花——书评《Java与模式》

（本文首发于《程序员》杂志2003年第1期）<o:p></o:p>

躺在我面前的，是阎宏博士编著、电子工业出版社出版的厚达1024页的《Java与模式》。如果按照我的朋友Jacques Lebrun在他的《The Mythical Man-Month：一次豆豆式的书评尝试》中的说法，这本书是要归于“体态狼伉”的“庞然巨物”的，而且恰好1K的页码数的确也很能“让人产生心理障碍”了。不过，由于本人研究模式理论有日，也知道在设计模式方面很难写出一本能“作掌上舞”的小书，所以，还是暂且抛开“豆豆式”的批评套路，回到严谨的批评上来。在《Java与模式》的序1中，朱天华博士将此书盛赞为“散发着奇妙香气的曼妙花朵”，而我对它的评价则是“一枝看上去很美的花”。

直到最近，中文的模式理论类书籍只有《设计模式》一本。《设计模式》的经典地位毋庸置疑，但是其中使用的范例太老旧，很难让读者获得直观的感性认识，兼之理论阐述太过抽象，导致阅读体验极差。《设计模式》的读者普遍反映“看不懂”，实是情理之中。而《Java与模式》是迄今为止第一本模式理论的中文入门教材，自然，也是最好的一本，因为并没有第二本。

对于《Java与模式》这本书，作者阎宏博士的期望并不仅仅是普及模式理论和设计模式技术，而且还希望探索模式理论的哲学根源，将设计模式技术与中国传统文化结合起来。这种技术的形而上学探索，便是朱博士所赞的“奇妙香气”，也正是笔者说它“看上去很美”的原因。在本文中，笔者也将对这两方面分别评论，以期给这本书一个全面而不失之偏颇的评价。

迄今为止最好的模式教材

一本模式教材应该是什么样子的？或者说，如何评价一本模式教材的优劣。

首先，这本书应该对C.Alexander的模式理论作必要的介绍。毕竟大多数读者接触“模式”这个词是从“设计模式”开始，他们学习模式的目的是提高软件开发的能力。模式教材的作者不可能也不应该假设他的读者都读过《建筑的永恒之道》。由于Alexander的模式理论对软件模式的形式、理论有着极其深远的影响，因此模式教材的作者应该帮读者补上这一课。

其次，这本书应该对面向对象的一些指导性原则作必要的介绍。像开放-封闭原则（OCP）、Liskov替换原则（LSP）、依赖倒转原则（ISP）等原则，是面向对象程序设计努力的方向。同样，一个负责的作者也不应该假设他的读者都读过Robert Martin的Designing Object Oriented C++ Applications Using The Booch Method，他也应该帮那些面向对象的初学者补上这一课。

第三，这本书应该对《设计模式》书中提到的大部分模式作足够详尽的介绍。由于《设计模式》的经典地位和它的枯燥晦涩，一本模式教材最应该做的就是不厌其详地介绍《设计模式》中一些重要模式的来龙去脉，说明它们为什么必要，说明它们的适用范围以及（更重要的）不适用的范围，说明它们如何解决问题以及遗留下的问题。如果不能解答《设计模式》给读者留下的这些疑问，一本模式教材将无法引起读者的共鸣，也无法给读者立竿见影的效用。

最后，书中的内容应该“与时俱进”。范例应该来自应用更为广泛的软件项目，语言最好是Java或者C#（由于C++内在的局限性，并不适合用于描述设计模式），图例应该用UML……尽管我很推崇Robert Martin那本书，但如果看到一本今天的模式教材还在用Booch方法，我一定先把它扔到一边去。

在我所见到的模式书籍中，Alan Shalloway的Design Patterns Explained和阎博士这本《Java与模式》都符合上述四点要求，所以都可以被评为“好的模式教材”；而Pattern Hatching、The Pattern Almanac等书则不符合上述要求，因此不是“好的模式教材”（请注意：不是好的模式教材，并不妨碍它们成为好的模式专著。但那不在我的评判范围之内，因此我不做评判。对适用范畴之外的事物保持恰当的沉默，是严谨的科学态度所必须的）。现在Design Patterns Explained尚未出版中译本，因此不论它是否优于《Java与模式》，后者都是迄今为止最好的中文模式教材。

除掉“Alexander的模式理论”和“面向对象设计原则”这两项要素之外，《Java与模式》这本书有两个值得注意的特点：第一，它采用了大量从金融业务系统中抽取出来的Java代码示例；第二，书中穿插着大量源自中国古典名著的哲学小品。关于第二个特点，我将在后面评论。至少，阎博士扎实的基础和长期在华尔街开发软件项目的经验使得这些范例不至于像《设计模式》中的范例那样生涩，也不至于像The Joy of Patterns中的范例那样流于简单。

但是，这并不意味着阎博士对模式的阐述并无缺陷。对于模式来说，除了“解决方案（solution）”之外，最重要的元素还包括“问题（problem）”、“约束（force）”和“效果（consequence）”。读者每学习一个模式，除了学到模式所代表的解决方案之外，还必须相应地学到该模式所适用的范围（由“问题”给出）、不适用的范围（由“约束”给出）和该模式造成的正反两面的效果。否则，读者仅学到一个解决方案，却不知道应该在何时使用（以及，在何时不使用），则只能靠自己在不断的试错过程中摸索该模式的约束条件。摸索模式的约束条件，与摸索问题的解决方案，两者的工作量往往相差无几——也就是说，模式将没有任何帮助。阎博士对此显然是很清楚的，在《Java与模式》的1.6节中，阎博士明确无误地列举出了模式的“十大要素”（包含了一些并非最重要的要素，如“范例[example]”、“已知应用[known uses]”等）。

可是，在讲解具体模式的时候，阎博士却忽略了“约束”这个重要的约束——至少是没有明确地在每个模式中指出。这种行文安排，或许是由于阎博士的哲学态度（关于这一点，我将在后面讨论）。但是，这种疏漏的后果可能是很严重的：缺乏（至少是不明确标明）约束条件的模式介绍，加上似是而非、放之四海皆准的哲学小品，可能很容易让读者对模式抱一种过分的乐观态度，并将对模式的误用归咎于没有获得那种无影无形的“道”，从而失去加深对模式认识的机会。甚至于，对于一个不太负责的读者，对约束条件的疏漏可能让全书的努力付诸东流。对于一本1K页的技术书籍来说，让读者冒着放弃科学意味的风险而追求哲学意味，成本恐怕太高了一点。努力地（也可能是一厢情愿地）为这种疏漏做一些补救，也是我写这篇书评的目的之一。

上面就是我对《Java与模式》这本书技术层面的评价，一言以蔽之曰：白璧微瑕。在Design Patterns Explained的中译本出版之前，这本书毫无疑问是最好的中文模式教材；即使Design Patterns Explained出版，由于中西文化上的差异和翻译水平的限制，它与读者的亲合度也未必强于《Java与模式》，因此后者也可能继续成为最好的中文模式教材。

前面已经提到，作者阎宏博士非常注重模式理论与中国传统思想的结合，全书也处处穿插着源自中国经典的哲学小品，并试图向读者传达一种中国道家思想的哲学意味。下面，我将对这种哲学意味进行评价。作为一个软件开发者，面对一本阐述软件开发技术的书籍，我将尽力把评论收敛在科学的范畴之内，并对科学所不能及的范畴保持恰当的沉默。如前所述，这是严谨的科学态度所必须的。艰难地、谨慎地、坚定地，我将开始了。

重要而非必要的哲学意味

综观全书，阎宏博士的论点大致可以总结为：

软件模式理论起源于C.Alexander的建筑模式理论，后者又起源于中国的道家思想。并且，模式理论与包括孙子、墨子等在内的中国传统思想多有暗合之处。因此，朝着中国传统思想的方向为模式理论做形而上学的探索，有助于发展“软件工程哲学”。<o:p></o:p>

对于阎博士赋予这本书的哲学意味（以及它占据的篇幅），我的评价是：重要，但非必要。说它“重要”，是因为它对于读者理解模式理论可能不无裨益——这是心理学范畴的价值，而非科学范畴的；说它“非必要”，是因为它在科学范畴没有任何价值，对模式的实际应用也并没有更多的助益。下面，我将详细阐述我的观点。

软件模式起源于C.Alexander的建筑模式理论，这是毫无疑问的。不论是GoF的《设计模式》、Alan Shalloway的Design Patterns Explained，还是Linda Rising的The Pattern Almanac，都强调Alexander的著作《建筑的永恒之道》和《建筑模式语言》对软件模式思想的影响。但是，Alexander的建筑模式理论（以及从它衍生而来的软件模式理论）是否起源于中国的道家思想，就有可商榷之处了。

中国的道家思想似乎是适用范围最为广泛的一种思想。天地运转、人情世故，似乎无不蕴涵在一句“道可道非常道”之中。这种极其广泛的适用性就给我们一个暗示：它很可能是一个并无意义的理论。从逻辑学的角度来说，一个矛盾式有无限大的信息量，可以从中推出任何命题。因此，只要用足够含混的语言把矛盾隐藏到一个命题中而不被发现，那么任何其他命题都可以从这个命题起源出来，因为后者已经是一个矛盾式了。以道家思想为例，对于《道德经》的第一句，大多数人的句读是“道可道，非常道”，意思是“道一旦被言说出来，就不成其为恒常的道”，这听起来很像维特根斯坦所说的“语言游戏”；而我的一位朋友ozzzzzz的句读却是“道可、道非，常道”，意思是“既容纳正面观点，也容纳反面观点，这就是恒常的道”，这听起来又更像是黑格尔的辨证法了。为什么出现这种情况？原因就在于：这句话足够含混，可以容许有不同的、甚至是矛盾的理解，因此可以从中推出任何理论——只要有足够的逻辑能力。说“模式理论起源于中国道家思想”，也是对这种逻辑能力的一次运用。

为了演示如何从矛盾式推出自己想要的理论，我的朋友Snowfalcon做了一个更有趣的实验。下面是Snowfalcon即兴写下的一段文字：

软件的永恒之禅<o:p></o:p>

模式的哲学可以追溯到佛教的起源。可以将佛教的理论“投射”到软件设计中。<o:p></o:p>

……<o:p></o:p>

首先，“无名特质”（QWAN）意味着一个软件的内在属性不仅仅存在于这个软件之中，而且存在于这个软件与其它软件的相互作用之中，存在于这个软件与计算机外部的世界，特别是用户的相互作用之中。<o:p></o:p>

“无名特质”其实在佛教中早已有详细的阐述。佛教中讲“空”就是这个概念。佛教中的“空”分为“人空”和“法空”。其中法空说的是“法空，则谓一切事物之存在皆由因缘而产生，故亦无实体存在”。也就是说，所有的事物都由内在的本质“因缘”所定，当它反映到人脑中则形成了“色法”。所谓“色法”，泛指有质碍之物，即占有一定之空间、具有自他互相障碍及会变坏之性质者。无名特质对应了空，它是一切事物的产生和内在的本质。但是由于人的观察，形成了色法。色法阻碍了人对事物即空的本质觉悟，从而说它是自他互相障碍。<o:p></o:p>

因此软件中这个最重要的属性之所以是“无名”的，是因为它是映射到人脑之前的属性。在这个属性被映射到人脑中之后，就已经经历了用各种方式局限到各种不同范围之内的过程；这种过程导致这个无名的质变成一大堆“有名”的“色法”。在本书后面读者会读到，这些“有名”的“色法”就包括软件性能要求的可变性、软件的可用性；以及系统的可扩展性、灵活性和可插入性等等。这些质就是色法，如果我们用色法去观察世界，那么就不能理解无名特质的本身的空。<o:p></o:p>

听起来是不是也很有道理？为什么“模式的哲学”既可以起源于道家思想，也可以起源于佛教？甚而至于，你可以感觉到：只要有足够的逻辑能力和语言能力，你还可以让“模式的哲学”起源于其他的很多思想。原因就在于：和道家思想一样，佛教的理论也用足够含混的语言包容了矛盾，因此能够从中推导出任何其他理论。

正如我所暗示的，还可以把这样的逻辑游戏继续玩下去。你甚至可以声称模式的哲学起源于柏拉图的思想：模式是“理型的解决方案”，是某一类具体解决方案的“灵魂”；具体解决方案是模式在真实世界的“投影”；当人们看到这些“投影”时，他们灵魂中的理性受到震荡，并因此而探寻完美的“理型”——也就是模式。当然，也可以声称模式的哲学起源于赫拉克利特的思想，只要你愿意。<o:p></o:p>

那么，这种理论的追根溯源有什么意义？答案是：在科学的范畴内，没有任何意义。正如上面所说，从矛盾式可以推出任何命题。整个推导过程仅仅是一个逻辑游戏，只是给同一个命题以不同的表达，而不能给出更多的信息。对于阎博士的这本书，情况正是这样：不论把模式理论归结于道家思想或者佛教思想或者别的什么思想，都不能给模式理论以更多的内涵。

除了提纲挈领的哲学思想之外，阎博士在书中处处采用的“文化小品”也有着同样的问题：它们对于理解单个的模式并无更多的帮助。这类来自中国古典名著的小故事，在点缀着读者的阅读体验的同时，也混淆着读者的头脑。读者在了解模式的方面节约了多少时间，就会在理解模式的方面浪费多少时间。

其实这种介绍模式的手法并不新鲜。就在CSDN网站上，我也不止一次地看到有人用比喻的手法来介绍设计模式（以及其他比较难理解的东西，例如面向对象），并美其名曰“深入浅出”之类。对于这种降低难度的办法，我一向不感冒。对于模式，最重要的元素莫过于“约束”——“问题”和“解决方案”都是一目了然的，但真正重要的是要知道“何时不使用模式”，也就是“约束”所讨论的东西。什么样的比喻能够描述出软件问题的复杂度？即使有这样的比喻，它又怎能不像软件问题一样难以理解？所以，我反对在讨论模式的时候滥用比喻——毕竟我们讨论的是软件问题的解决方案，而不是那些看似轻松的比喻。

即使是阎博士精心挑选的比喻，也同样无法令人满意。我随手捡一个例子：

孙悟空在与黄风怪的战斗中，“使一个身外身的手段：把毫毛揪下一把，用口嚼得粉碎，望上一喷，叫声‘变！’变有百十个行者，都是一样打扮，各执一根铁棒，把那怪围在空中。” 换言之，孙悟空可以根据自己的形像，复制出很多“身外之身”来。<o:p></o:p>

老孙的这种身外身的手段在面向对象的设计领域里，叫做原始模型（Prototype）模式。<o:p></o:p>

这就是典型的过分简化的比喻：既然可以说这种“身外身”的手段是Prototype模式，那么我可不可以说它是Factory Method模式呢？又可不可以说它是Singleton模式呢？又可不可以说它是Flyweight模式呢？这样一个“案例”，既不能说明模式的“问题”，也不能说明模式的“约束”——如果讨论设计模式而不说明“问题”和“约束”，那讨论就没有任何意义。这样的比喻，简单则简单矣，恐怕读者看完了例子还是如坠云中，不知道自己的软件中是不是适合用这种“身外身的手段”。

到此，读者可以看到我的观点：阎博士给这本《Java与模式》赋予的哲学意味、文化意味，不论是提纲挈领的哲学渊源，还是贯穿全书的文化小品，对于模式的知识都并无助益。因此，我认为它并非必要。这对于那些想要通过这本书“得道”而掌握模式精髓的读者，无疑是一个打击，不过也应了最近又开始流行的一句老话：No silver bullet。

尽管并非必要，但这些内容的确有其价值——不是科学范畴的，而是心理学范畴的。书中的哲学意味尽管不能给读者更多的模式理论，但的确能够吸引中国读者的眼球，让他们有兴趣捧起这本书来；书中的文化小品尽管不能让读者更好地理解模式，但的确能够调节读者的阅读体验，让他们不至于疲惫地把书扔到一边。同样，这些比喻也可以让读者更快地对模式有一个大致的了解，虽然他们会在需要使用模式的时候花掉更多的时间去摸索模式的适用范围。

这就是我对《Java与模式》中哲学意味的综合评价：重要，但非必要。你可以把它们当作很好的调节剂（当然也可能被看成使用不当的稀释剂，这取决于个人爱好），但不要希望能从中学到更多的什么东西。老子的“道”说了上千年，终于还是没有人“得道”。

写在最后

如果可以的话，我宁可不要对《Java与模式》的哲学意味做任何评价，因为这种纠缠了哲学、逻辑和科学的文字写来实在费劲。只是，作者阎宏博士对他书中的哲学意味如此看重，我如果评价他的书而不评价这一部分，对他是大不恭，故此勉力为之。现在，我终于又可以回到轻松的书评路线上来了。

借用Jacques Lebrun的那句“法国人的俏皮话”来评价阎宏博士：他没有时间往短里写。这本《Java与模式》会有1K页这么厚，阎博士的“贪心”是肇因——想在一本书里放下模式理论起源、模式基础和模式实例，而且还不愿厚此薄彼，最后的成果变成“狼伉巨物”也就是情理之中了。不过，这种“贪心”的风格把这本书置于一个略显尴尬的境地：它太大，无法成为公共汽车上的阅读物；如果要当参考手册来看，又显得太稀——在查阅一个急需的模式时，恐怕是不会有太多人有心情顺便欣赏“孙大圣大战黄风怪”的。所以，尽管这是一本很好的书，我却不知道该在什么时间读它。至少，我不会愿意在公车上捧着一本1K页的书，所以，它还是尴尬地躺在我办公室的抽屉里。

所以，这本《Java与模式》的确是一本好书，如果你有足够的耐性来读它的话——我已经没有这样的耐性了。实际上，我现在看到超过500页的书就会退避三舍。不过，除掉其中那些有助于消化的、带有淡淡甜味的辅料之外，它能给读者的养分与它1K的页码并不相称。对此，我也只能希望阎博士能够有时间把这本书“往短里写”了。