就他吧-9ta8为您提供:身份证查询、15位转16位身份证,手机号码归属地查询,IP地址查询服务,城市天气预报查询,列车时刻表简易快速查询等等查询服务,就他吧欢迎您的光临!!
随笔- 96  评论- 750  文章- 16 

如何在实际工作中发现模式(一)

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

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

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

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

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

        一个问题的实例是“如何管理Web窗体的状态?”

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

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

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

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

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

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

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

posted on 2005-08-18 08:34  振河  阅读(2827)  评论(1编辑  收藏

  就他吧-9ta8伴您开心每一天