1.3 设计模式要素

描述设计模式需要一定的格式，可采用的格式有很多，在 Alexander 的著作中使用的格式就叫做Alexander格式，在GoF的著作中使用的格式就叫做GoF格式。在GoF格式中，沿用了一些Alexander格式的段落标题，这些标题常常叫做正则格式。尽管在不同的格式中，正则格式的细节有所不同，但设计模式应当包含以下几个要素。

■ 模式名称（pattern name）

设计模式的名称简洁地描述了设计模式的问题、解决方案和效果。一个模式必须有一个有意义的、简短而准确的名字。好的模式名称便于设计人员之间交流思想，进行抽象讨论及研究设计结果。找到恰当的模式名称也是设计模式编目工作的难点之一，命名一个新的模式，就可以讨论模式并在编写文档时使用它们。

■ 问题（problem）

描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等，也可能描述了导致不灵活设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。

■ 环境或初始环境（context或initial context）

环境说明模式的使用范围，也是模式应用之前的起始条件（也叫前提条件）。

■ 解决方案（solution）

描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。模式就像一个模板，可应用于多种不同场合，因此解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象组合）来解决这个问题。

■ 效果（consequences）

描述了模式应用的效果及使用模式应权衡的问题。效果用来描述设计模式的利弊，它往往是衡量模式是否可用的重要因素，对于评价设计选择和理解使用模式的代价及好处具有重要意义。软件效果大多关注对时间和空间的衡量，表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括其对系统的灵活性、扩展性或可移植性的影响，显式地列出这些效果对理解和评价这些模式具有很大的帮助。

■ 举例（examples）

使用一个或多个示意性的应用来说明特定的真实环境，以及模式是如何应用到环境中、改变环境并且给出当模式结束时的末态环境。例子有助于理解模式的使用方法和适用性，每一个例子均可以附带一个实现的样本，说明解答是如何给出来的。从熟知系统里取出来的、有视觉效果的，或以比喻方式表达的例子，更易于使用者理解。

■ 末态环境（resulting context）

模式应用到系统之后的状态。末态环境包括模式带来的好结果和坏结果，以及新状态中含有的其他问题和可能涉及的其他有关系的模式。末态环境是模式的末态条件和可能有的副作用。描述末态环境可以帮助比较末态环境与起始环境的区别和联系。

■ 推理（rationale）

推理解释本模式的步骤、规则，以及此模式作为一个整体是如何以特定的方式解决模式的。推理让使用者知道模式是如何工作的，为什么可以工作，以及使用此模式的优点是什么。模式的解答描述模式外部的、可见的结构和行为，而推理则给出模式在系统表层以下的深层结构和关键机制。

■ 其他有关模式（related pattern）

描述在现有的系统中此模式与其他模式的静态和动态的关系。相关模式的初始环境和末态环境经常是相容的，这些模式有可能是本模式的前任模式，即应用了这些模式可以给出本模式的初始环境，也有可能是本模式的继任模式，即本模式的应用给出这些模式的初始环境。这些模式还有可能是本模式的替换模式，即给出相同问题的不同解答，也有可能是本模式的相互依赖的模式，可以或必须和本模式同时使用。

■ 已知的应用（known uses）

已知的应用是在已有的系统模式中出现和应用的例子，有助于证明此模式确实是对一个重复发生的问题可行的解答。已知的应用经常成为教学用的教材。

任何对模式的讲解或者论述必须依据一定的格式，正如GoF格式一样，所有的模式都应当包括模式的所有要素。