【IT168技术文档】
前提
模式的发现是可遇不可求的，既然是发现，就有机会的成分存在。不可能当我们希望发现模式时就一定能够发现，困此发现模式的第1个前提是不要为了发现而发现，这样你会失望的。然而，机会从来是被有准备的人抓住的。重构原有的项目、学习同行的经验和总结是发现模式的最好时机。需要强调的是，不仅仅只有设计模式，分析模式和过程模式等都是我们发现的目标；第2个前提是要把握住发现模式的时机。如果项目正处在紧要关头，而你有了新发现，却没有时间，这时千万记住要把想法记录下来，这是最宝贵的素材。
确定范围
当你感觉到某些问题似曾相识，在解决问题时似乎曾经重复用到某些思路时，可能就是你遇到了潜在的模式。首先要做的是将问题的范围确定下来，如问题是否可以分解为子问题？其相关的因素是什么？如果问题针对的是具体的平台或语言，你发现的可能是一种“方言”；如果问题比较复杂，你可能需要用模式语言来描述一组模式。
确定范围的另一个工作是需要将似曾相识的问题收集起来，因为模式是反复出现的问题的抽象，因此一定要有反复使用的实例作为模式形成的基础。应该注意的是，收信的范围不限于自己完成的项目，也可以是他人的成果，如开放源代码项目和商业软件等。只有确信发现的问题和对应的解决方案是反复出现的，才可能进一部将其归纳为模式。经常是在收集的过程中，会发现一些表面类似的问题实际上并不相同，或者是所处的场景不同，或者是问题的本质不同。
明确问题及其所处的上下文
如果问题明确，就等于解决了一半，而明确问题往往是很困难的。很多情况下，我们在意识上已经知道了问题是什么，但是却难以言表。回想一下我们已经学习过的设计模式，是否能用一句话说出需要解决的问题？看一看GOF给出的意图，就会发现这是一个相当困难的事情。
因此一个好的方法是从具体到一般，即先将问题存在的某个具体环境描述清楚。丰书在描述模式时，很多章节的引言就是起这个作用。如果我们不能一次完成抽象，就让我们从具体开始，这类似于GOF的动机描述。当一个具体场景用文字描述清楚后，即可着手发现这个场景中的一般规律，这就是问题所处的上下文。经常在我们分析上下文后，即可以将问题归纳出来。
一个问题的实例是“如何管理Web窗体的状态？”
这个问题的上下文环境是“在Web应用中，需要Web窗体保存状态，以便于用户与应用之间的交互。而Web窗体存在于浏览器，由于HTTP会话的无状态特点，单纯的浏览器-Web服务器无法保存Web窗体的状态”。
确定Forces
Forces是模式的特点，也是最重要的部分之一，尽管GOF的设计模式结构中没有这个部分。要知道我们中的大部分人达不到GOF的水平，因此还是要将Forces明确地写出。如果你希望在模式社会中进行交流，那么这一点非常重要。
Forces的作用在于展示解决方案的必要性，即说明在查找问题的解决方案时需要考虑的各方面的因素。这些因素往往是互相制约的，解决问题可能需要付出某种代价。Forces列出的可能是后选的方案和代价，也可能是相关的潜在问题。
如下是一些可能的Forces。
（1）在网页中增加隐含域，在隐含域中保存相应的状态。然而这样一方面增加了网络的负荷（因为状态值需要反复传递），另一方面安全性不好，通过查看页面的HTML代码可以获得并修改页面状态。
（2）可以在数据库中保存网页的状态，然而这样会增加系统的复杂程度和成本。
（3）可以采用.NET提供的视图功能保存窗体中控件的状态，然而视图会大量增加页面代码量，网络负荷会明显增大并且没有从根本上解决安全问题。
（4）可以在Cookie中保存状态，然而有些浏览器不支持Cookie且有潜在的安全问题。
如果你的模式是“在Session中保持窗体状态”，那么上面的Forces已经说明了你为什么选择对应的解决方案了。
描述解决方案
如果Forces描述非常吸引人，那么用户会迫切希望知道解决方案。软件开发人员通常希望采用图示法描述解决方案，因为一张图胜过千行字。然而需要注意的是，如果采用图示，一定要确保用户知道图示的含义。如果采用UML等标准的图示语言，一定要准确合理；如果是非标准的图示，一定要注明图例的含义。还需要注意的是，不仅仅要描述静态模型，还要描述动态模型。
尽管图示非常有用，但仍代替不了文字描述。对图中的元素一定要进行适当描述，以避免对图的。很显然，如果不加描述，很难理解下图所表达的内容是什么。
这里使用的是组合模式？装饰模式？代理模式？还是未使用什么模式？
效果
对效果的描述是模式的另一个重要特点。需要注意的是，效果描述的不仅仅是使用模式获得的好处，更重要的是需要描述使用模式的代价。好处经常是显而易见的，而代价则经常被忽略。这些代价有时不仅仅是单纯设计上的代价，还需要考虑开发过程和成本。
常见的代价如下。
（1） 复杂性提高，伴随复杂性提高的其他代价是测试难度增大，难以理解等。
（2） 对安全性的影响。
（3） 成本提高，如需要数据库支持等。
（4） 交互复杂，从而产生网络流量增加等其他代价。
（5） 对部署的影响。
模式名称
根据经验，为模式命名一个有代表性的名字并不是一件容易的事情。名称可能表示模式的结构，如“桥接”或“组合”。也可能表示模式的意图，如“抽象工厂”。也可能是模式的某个组成部分，如“生成器”。不管怎样，模式的名称非常重要，因为可以简化使用模式时的交流。
模式的其他部分
模式的其他部分包括“已知应用”、“相关模式”和“示例”等，这些同样是模式不可缺少的组成部分。如果你希望完成一个完整的模式，则必须包括所有这些部分。
