什么是设计模式

        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）描述了模式应用的效果及使用模式应权衡的问题。