设计模式

模式是指从某个具体的形式中得到的一种抽象，在特殊的非任意性的环境中，该形式不断地重复出现。软件架构的模式描述了一个出现在特定设计语境中的特殊的再现设计问题，并为它的解决方案提供了一个经过充分验证的通用图示。解决方案图示通过描述其组成构件及其责任和相互关系以及它们的协作方式来具体指定

设计模式的组成

一般来说，一个模式有4个基本成分，分别是模式名称、问题、解决方案和效果

(1)模式名称。每个模式都有一个名字，帮助我们讨论模式和它所给出的信息。模式名称通常用来描述一个设计问题、它的解法和效果，由一到两个词组成。模式名称的产生使我们可以在更高的抽象层次上进行设计并交流设计思想。

(2)问题问题告诉我们什么时候要使用设计模式、解释问题及其背景。例如，MVC(Model-View-Controler，模型-视图-控制器)模式关心用户界面经常变化的问题。它可能描述诸如如何将一个算法表示成一个对象这样的特殊设计问题。在应用这个模式之前，也许还要给出一些该模式的适用条件。

(3)解决方案。解决方案描述设计的基本要素，即它们的关系、各自的任务以及相互之间的合作。解决方案并不是针对某一个特殊问题而给出的。设计模式提供有关设计问题的一个抽象描述以及如何安排这些基本要素以解决问题。一个模式就像一个可以在许多不同环境下使用的模板，抽象的描述使我们可以把该模式应用于解决许多不同的问题。

模式的解决方案部分给出了如何解决再现问题，或者更恰当地说是如何平衡与之相关的强制条件。在软件架构中，这样的解决方案包括如下两个方面。第一，每个模式规定了一个特定的结构，即元素的一个空间配置。例如，MVC模式的描述包括以下语句:“把一个交应用程序划分成三个部分分别是处理输入和输出”第二，每个模式规定了运行期间的行为。例如，MVC模式的解决方案部分包括以下陈述:“控制器接收输入，而输入往往是鼠标移动、点击鼠标按键或键盘输入等事件。事件转换成服务请求，这些请求再发送给模型或视图”。

解决方案不必解决与问题相关的所有强制条件，而是可以集中于特殊的强制条件，对于剩下的强制条件进行部分解决或完全不解决，特别是强制条件相互矛盾时。

(4)效果。效果描述应用设计模式后的结果和权衡。比较与其他设计方法的异同得到应用设计模式的代价和优点。对于软件设计来说，通常要考虑的是空间和时间的权衡。也会涉及到语言问题和实现问题。对于一个面向对象的设计而言，可重用性很重要效果还包括对系统灵活性、可扩充性及可移植性的影响。明确看出这些效果有助于理解和评价设计模式。

模式和软件架构

判断模式取得成功的一个重要准则是它们在多大程度上达到了软件工程的目标。模式必须支持复杂的、大规模系统的开发、维护以及演化。

1.模式作为架构构造块

已经知道，在开发软件时，模式是处理受限的特定设计方面的有用构造块。因此对软件架构而言，模式的一个重要目标就是用已定义属性进行特定的软件架构的构造例如，MVC模式提供了一个结构，用于交互应用程序的用户界面的裁剪软件架构的一般技术，例如使用面向对象特征(如继承和多态性)，并没有针对特定问题的解决方案。绝大多数现有的分析和设计方法在这一层次也是失败的。它们仅仅提供构建软件的一般技术，特定架构的创建仍然基于直觉和经验。模式使用特定的面向问题的技术来有效补充这些通用的与问题无关的架构技术。注意，模式不会舍弃软件架构的现有解决方案，相反，它们填补了一个没有被现有技术覆盖的缺口。

2.构造异构架构

单个模式不能完成一个完整的软件架构的详细构造，它仅仅帮助设计师设计应用程序的某个方面。然而，即使正确设计了这个方面，整个架构仍然可能达不到期望的所有属性。为了整体上达到软件架构的需求，需要一套丰富的涵盖许多不同设计问题的模式可获得的模式越多，能够被适当解决的设计问题也会越多，并且可以更有力地支持构造带有已定义属性的软件架构。

为了有效使用模式，需要将它们组织成模式系统。模式系统统一描述模式，对它们分类，更重要的是，说明它们之间如何交互。模式系统也有助于设计师找到正确的模式来解决一个问题或确认一个可选解决方案。这和模式目录相反，在模式目录中每个模式描述的多少与别的模式无关。

3.模式和方法

好的模式描述也包含它的实现指南，可将其看成是一种微方法，用来创建解决一个特定问题的方案。通过提供方法的步骤来解决软件开发中的具体再现问题，这些微方法补充了通用的但与问题无关的分析和设计方法。

4.模式的实现

从模式与软件架构的集成中产生的另一个方面是用来实现这些模式的一个范例。目前的许多软件模式具有独特的面向对象风格。所以，人们往往认为，能够有效实现模式的唯一方式是使用面向对象编程语言，其实不然。

一方面，许多模式确实使用了诸如多态性和继承性等面向对象技术。策略模式和代理模式是这种模式的例子;另一方面，面向对象特征对实现这些模式并不是最重要的。例如，在C语言中实现策略模式可以通过采用函数指针来代替多态性和继承性。

在设计层次，大多数模式只需要适当的编程语言的抽象机制，如模块或数据抽象。因此，可以用几乎所有的编程范例并在几乎所有的编程语言中来实现模式。另外，每种编程语言都有它自己特定的模式，即语言的惯用法。这些惯用法捕获了现有的有关该语言的编程经验并为它定义了一个编程风格。

设计模式的分类

1. Coad 的面向对象模式

Peter Coad从MVC的角度对面向对象系统进行了讨论，设计模式由最底层的构成部分(类和对象)及其关系来区分。他使用了一种通用的方式来描述一种设计模式，将模式划分为以下三类。

(1)基本的继承和交互模式。主要包括OOP 所提供的基本建模功能，继承模式声明了类能够在其子类中被修改或被补充,交互模式描述了在有多个类的情况下消息的传递。

(2)面向对象软件系统的结构化模式。描述了在适当情况下，一组类如何支持面向对象软件架构的建模。主要包括条目 (item)描述模式、为角色变动服务的设计模式和处理对象集合的模式

(3)与MVC框架相关的模式。几乎所有由 Peter Coad 提出的模式都指明了如何构造面向对象的软件，有助于设计单个的或者一小组构件，描述了 MVC框架的各个方面但是，他没有重视抽象类和框架，没有说明如何改造框架

2.代码模式

代码模式的抽象方式与OOP语言中代码规范很相似,该类模式有助于解决某种OOP语言中的特定问题。代码模式的主要目标如下

(1)指明结合基本语言概念的可用方式

(2)构成源码结构与命名规范的基础。

(3)避免OOP 语言(尤其是 C++语言)的缺陷。

代码模式与具体的程序设计语言或者类库有关，它们主要从语法的角度对于软件系统的结构方面提供一些基本的规范。这些模式对于类的设计不适用，同时也不支持程序员开发和应用框架，命名规范是类库中名字标准化的基本方法，以免在使用类库时产生混淆。

3.框架应用模式

在应用程序框架“菜谱”(application framework cookbook recipes)中有很多“菜谱条”，它们用一种不是很规范的方式描述了如何应用框架来解决特定的问题。程序员将框架作为应用程序开发的基础，特定的框架适用于特定的需求。“莱谱条”通常并不讲解框架的内部设计实现，只讲如何使用。

4.形式合约

形式合约(formal contracts)也是一种描述框架设计的方法，强调组成框架的对象间的交互关系。有人认为它是面向交互的设计，对其他方法的发展有启迪作用。但形式化方法由于其过于抽象，而有很大的局限性，仅在小规模程序中使用形式合约模式有如下优点。

(1)符号所包含的元素很少，并且其中引入的概念能够被映射成为面向对象程序设计语言中的概念。例如，参与者映射成为对象。

(2)形式合约中考虑到了复杂行为是由简单行为组成的事实，合约的修订和扩充操作使得这种方法很灵活，易于应用。

形式合约模式有以下三个缺点

(1)在某些情况下很难用，过于繁琐。若引入新的符号，则又使符号系统复杂化。

(2强制性的要求过分精密，从而在说明中可能发生隐患(例如几余)。

(3)形式合约的抽象程度过低，接近 OOP 语言，不易分清主次。

5.设计模式目录的内容

Erich Gamma在他的博士论文中总结了一系列的设计模式，做出了开创性的工作。他用一种类似分类目录的形式将设计模式记载下来，我们称这些设计模式为设计模式目录。根据模式的目标(所做的事情)，可以将它们分成创建性模式 (creational)、结构性模式(structural)和行为性模式(behavioral)。创建性模式处理的是对象的创建过程，结构性模式处理的是对象/类的组合，行为性模式处理类和对象间的交互方式和任务分布。根据它们主要的应用对象，又可以分为主要应用于类的和主要应用于对象的。

下表是ErichGamma等人总结的23种设计模式，这些设计模式通常被称为GoF （Gang of Four，四人组)模式。因为这些模式是在Design Patterns: Elements of Reusable Object-Oriented Software 一书中正式提出的，而该书的作者是 Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides，这几位作者常被称为“四人组”。