如何在实际工作中发现模式（一）

１．前提
        模式的发现是可遇不可求的，既然是发现，就有机会的成分存在。不可能当我们希望发现模式时就一定能够发现，困此发现模式的第１个前提是不要为了发现而发现，这样你会失望的。然而，机会从来是被有准备的人抓住的。重构原有的项目、学习同行的经验和总结是发现模式的最好时机。需要强调的是，不仅仅只有设计模式，分析模式和过程模式等都是我们发现的目标；第２个前提是要把握住发现模式的时机。如果项目正处在紧要关头，而你有了新发现，却没有时间，这时千万记住要把想法记录下来，这是最宝贵的素材。

２．确定范围
        当你感觉到某些问题似曾相识，在解决问题时似乎曾经重复用到某些思路时，可能就是你遇到了潜在的模式。首先要做的是将问题的范围确定下来，如问题是否可以分解为子问题？其相关的因素是什么？如果问题针对的是具体的平台或语言，你发现的可能是一种“方言”；如果问题比较复杂，你可能需要用模式语言来描述一组模式。

        确定范围的另一个工作是需要将似曾相识的问题收集起来，因为模式是反复出现的问题的抽象，因此一定要有反复使用的实例作为模式形成的基础。应该注意的是，收信的范围不限于自己完成的项目，也可以是他人的成果，如开放源代码项目和商业软件等。只有确信发现的问题和对应的解决方案是反复出现的，才可能进一部将其归纳为模式。经常是在收集的过程中，会发现一些表面类似的问题实际上并不相同，或者是所处的场景不同，或者是问题的本质不同。

３．明确问题及其所处的上下文
        如果问题明确，就等于解决了一半，而明确问题往往是很困难的。很多情况下，我们在意识上已经知道了问题是什么，但是却难以言表。回想一下我们已经学习过的设计模式，是否能用一句话说出需要解决的问题？看一看ＧＯＦ给出的意图，就会发现这是一个相当困难的事情。

        因此一个好的方法是从具体到一般，即先将问题存在的某个具体环境描述清楚。丰书在描述模式时，很多章节的引言就是起这个作用。如果我们不能一次完成抽象，就让我们从具体开始，这类似于ＧＯＦ的动机描述。当一个具体场景用文字描述清楚后，即可着手发现这个场景中的一般规律，这就是问题所处的上下文。经常在我们分析上下文后，即可以将问题归纳出来。

        一个问题的实例是“如何管理Ｗeb窗体的状态？”

        这个问题的上下文环境是“在Ｗeb应用中，需要Ｗeb窗体保存状态，以便于用户与应用之间的交互。而Web窗体存在于浏览器，由于ＨＴＴＰ会话的无状态特点，单纯的浏览器-Web服务器无法保存Web窗体的状态”。

４．确定Forces
        Forces是模式的特点，也是最重要的部分之一，尽管GOF的设计模式结构中没有这个部分。要知道我们中的大部分人达不到ＧＯＦ的水平，因此还是要将Forces明确地写出。如果你希望在模式社会中进行交流，那么这一点非常重要。

        Forces的作用在于展示解决方案的必要性，即说明在查找问题的解决方案时需要考虑的各方面的因素。这些因素往往是互相制约的，解决问题可能需要付出某种代价。Forces列出的可能是后选的方案和代价，也可能是相关的潜在问题。
如下是一些可能的Forces。

（1）在网页中增加隐含域，在隐含域中保存相应的状态。然而这样一方面增加了网络的负荷（因为状态值需要反复传递），另一方面安全性不好，通过查看页面的HTML代码可以获得并修改页面状态。

（2）可以在数据库中保存网页的状态，然而这样会增加系统的复杂程度和成本。

（3）可以采用.NET提供的视图功能保存窗体中控件的状态，然而视图会大量增加页面代码量，网络负荷会明显增大并且没有从根本上解决安全问题。

（4）可以在Cookie中保存状态，然而有些浏览器不支持Cookie且有潜在的安全问题。
        如果你的模式是“在Session中保持窗体状态”，那么上面的Forces已经说明了你为什么选择对应的解决方案了。