什么是设计模式

        Christropher Alexander:每一个模式描述了一个我们周围不断重复发生的问题,以及问题的解决方案的核心。这样,你就能一次又一次地使用该方案而不必做重复劳动。[AIS+77,第10页]。

这里要说明一下,Alexander所指的是城市和建筑模式。因为也有人说他这种说法是不正确的(http://www.cnblogs.com/me-sa/articles/565592.html,以下一段是原话)

*********************************************************************

误解之一:“模式是某种场景下某个问题的解决方案”

  这个定义来自于Christopher Alexander[AIS+77],所以如果把它称为“误解”,也许有人会把我目为异端。但是下面这个简单的反例就能让你看清它的缺点:

  问题:我获奖的奖券就快过期了,我怎样拿到奖金?
  场景:离截止时间只有一小时,可是我家的小狗把奖券给吞了。
  解决方案:把狗开膛破肚,掏出奖券,然后飞奔到最近的兑奖地点。

  这是“某种场景下某个问题的解决方案”,但它不是模式。还缺了什么?至少缺三样东西:

  1. 可重复性。解决方案应该对应于外部的场景。
  2. 可传授性。一个解决方案应该可以移植到问题的不同情况上。(绝大多数模式的可传授性都建立在“约束”和“效果”的基础上。)
  3. 用来表示这个模式的名称。

  确实,很难找到一个令人满意的定义。“模式讨论”邮件列表(patterns-discussion@cs.uiuc.edu)上正在进行的讨论也证明了这一点。难以定义的一大原因是:模式既是一个事物,也是对类似事物的描述。要区分这两者,有一种办法:“模式”这个术语只用来指代模式的描述,同时用“模式实例”来指代模式的具体应用。

  但是,术语的定义很可能是白费力气,因为一个定义可能对一个人(比如程序员)有意义,但是对另一个人(比如只能看到书面材料的项目主管)却毫无意义。当然,我不打算在这里提出什么最终定义。但是,任何对模式要素的规定,除了必须包括问题、解决方案和场景之外,都必须提及可重复性、可传授性和名称。

***********************************************************************************

        这里,但是Alexander的思想是适用于面向对象设计模式的,只是在面向对象的解决方案里,我们用对象和接口代替了墙壁和门窗。两类模式的核心都在于提供了相关问题的解决方案。(上面认为Alexander是错误的,没有指明Alexander指的是什么,而且上面这个是一个特例,不至于很多人都遇到这样的场景,涉及不到复用的问题。)

一个模式有四个基本要素:

1.模式名称(Pattern Name)一个助记名,它用一两个描述模式的问题、解决方案和效果。

2.问题(Problem)描述了应该何时使用模式。

3.解决方案(Solution)描述了设计的组成成分,他们之间的相互关系及各自的职责和协作方式。

4.效果(Comsequences)描述了模式应用的效果及使用模式应权衡的问题。

 

 

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值