0.5 模式

模式的概念早就有了。我在这里不想把这段历史重新演绎一遍。只是想简单谈谈我对模式和它们为什么是描述设计的重要手段的一些看法。

模式没有统一的定义，可能最好的起点是Christopher Alexander给出的定义（这也是许多模式狂热者的灵感来源）：“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”[Alexander et al.]。尽管Alexander是建筑家，他谈论的是建筑模式，但其定义也能很好地适用于软件业。模式的核心就是特定的解决方案，它有效而且有足够的通用性，能解决重复出现的问题。模式的另一种视角是把它看成一组建议，而创造模式的艺术则是将很多建议分解开来，形成相互独立的组，在此基础上可以相对独立地讨论它们。

模式的关键点是它们源于实践。必须观察人们的工作过程，发现其中好的设计，并找出“这些解决方案的核心”。这并不是一个简单的过程，但是一旦发现了某个模式，它将是非常有价值的。对于我来说，价值之一是能够撰写这样一本参考书。你不必通读本书的全部内容，也不必通读所有关于模式的书。你只需要了解到这些模式都是干什么的、它们解决什么问题、它们是如何解决问题的，就足够了。这样，一旦碰到类似问题，就可以从书中找出相应的模式。那时，再深入了解相应的模式也不迟。

一旦需要使用模式，就必须知道如何将它运用于当前的问题。使用模式的关键之一是不能盲目使用，这也是模式工具为什么都那么惨。我认为模式是一种“半生不熟品”，为了用好它，还必须在自己的项目中把剩下的那一半“火候”补上。我本人每次在使用模式时，都会东改一点西改一点。因此你会多次看到同一个解决方案，但没有一次是完全相同的。

每个模式相对独立，但又不彼此孤立。有时候它们相互影响，如影随形。例如，如果在设计中使用了领域模型，那么经常还会用到类表继承。模式的边界本来也是模糊的，我在本书中也尽量让它们各自独立。如果有人说“使用工作单元”，你就可以直接去看工作单元这个模式如何使用，而不必阅读全书。

如果你是一个有经验的企业应用设计师，也许会对大多数模式都很熟悉。希望本书不会给你带来太大的失望。（实际上我在前言里面已经提醒过了。）模式不是什么新鲜概念。因此，撰写模式书籍的作者也不会声称我们“发明”了某某模式，而是说我们“发现”了某某模式。我们的职责是记录通用的解决方案，找出其核心，并把最终的模式记录下来。对于一个高级设计师，模式的价值并不在于它给予你一些新东西，而在于它能帮助你更好地交流。如果你和你的同事都明白什么是远程外观，你就可以这样非常简捷地交流大量信息：“这个类是一个远程外观模式。”也可以对新人说：“用数据传输对象模式来解决这个问题。”他们就可以查找本书来搞清楚如何做。模式为设计提供了一套词汇，这也是模式的名字如此重要的原因。

本书的大多数模式是用来解决企业应用的，基本模式一章（见第18章）则更通用一些。我把它们包含进来的原因是：在前面的讨论中，我引用了这些通用的模式。