|
|
|
模式是指从某个具体的形式中得到的一种抽象，在特殊的非任意性的环境中，该形式不断地重复出现。软件体系结构的模式描述了一个出现在特定设计语境中的特殊的再现设计问题，并为它的解决方案提供了一个经过充分验证的通用图示。解决方案图示通过描述其组成构件及其责任和相互关系以及它们的协作方式来具体指定。
|
|
|
|
|
|
一般来说，一个模式有4个基本成分，分别是模式名称、问题、解决方案和效果。
|
|
|
|
（1）模式名称。每个模式都有一个名字，帮助我们讨论模式和它所给出的信息。模式名称通常用来描述一个设计问题、它的解法和效果，由一到两个词组成。模式名称的产生使我们可以在更高的抽象层次上进行设计并交流设计思想。
|
|
|
|
（2）问题。问题告诉我们什么时候要使用设计模式、解释问题及其背景。例如，MVC（Model-View-Controler，模型－视图－控制器）模式关心用户界面经常变化的问题。它可能描述诸如如何将一个算法表示成一个对象这样的特殊设计问题。在应用这个模式之前也许还要给出一些该模式的适用条件。
|
|
|
|
（3）解决方案。解决方案描述设计的基本要素，它们的关系、各自的任务以及相互之间的合作。解决方案并不是针对某一个特殊问题而给出的。设计模式提供有关设计问题的一个抽象描述以及如何安排这些基本要素以解决问题。一个模式就像一个可以在许多不同环境下使用的模板，抽象的描述使我们可以把该模式应用于解决许多不同的问题。
|
|
|
|
模式的解决方案部分给出了如何解决再现问题，或者更恰当地说是如何平衡与之相关的强制条件。在软件体系结构中，这样的解决方案包括两个方面。
|
|
|
|
第一，每个模式规定了一个特定的结构，即元素的一个空间配置。例如，MVC模式的描述包括以下语句：“把一个交互应用程序划分成3部分，分别是处理、输入和输出”。
|
|
|
|
第二，每个模式规定了运行期间的行为。例如，MVC模式的解决方案部分包括以下陈述：“控制器接收输入，而输入往往是鼠标移动、单击鼠标或键盘输入等事件。事件转换成服务请求，这些请求再发送给模型或视图”。
|
|
|
|
解决方案不必解决与问题相关的所有强制条件，而是可以集中于特殊的强制条件，对于剩下的强制条件进行部分解决或完全不解决，特别是强制条件相互矛盾时。
|
|
|
|
（4）效果。效果描述应用设计模式后的结果和权衡。比较与其他设计方法的异同，得到应用设计模式的代价和优点。对于软件设计来说，通常要考虑的是空间和时间的权衡。也会涉及到语言问题和实现问题。对于一个面向对象的设计而言，可重用性很重要，效果还包括对系统灵活性、可扩充性及可移植性的影响。明确看出这些效果有助于理解和评价设计模式。
|
|
|
|
|
|
本节简单地介绍设计模式的分类，有关各模式的具体实现，请参考专门讨论设计模式的书籍。
|
|
|
|
|
|
Peter Coad从MVC的角度对面向对象系统进行了讨论，设计模式由最底层的构成部分（类和对象）及其关系来区分。他使用了一种通用的方式来描述一种设计模式，将模式划分为以下三类。
|
|
|
|
（1）基本的继承和交互模式：主要包括OOP所提供的基本建模功能，继承模式声明了类能够在其子类中被修改或被补充，交互模式描述了在有多个类的情况下消息的传递。
|
|
|
|
（2）面向对象软件系统的结构化模式：描述了在适当情况下，一组类如何支持面向对象软件体系结构的建模。主要包括条目（item）描述模式、为角色变动服务的设计模式和处理对象集合的模式。
|
|
|
|
（3）与MVC框架相关的模式。几乎所有的由Peter Coad提出的模式都指明了如何构造面向对象的软件，有助于设计单个的或者一小组构件，描述了MVC框架的各个方面。但是，他没有重视抽象类和框架，没有说明如何改造框架。
|
|
|
|
|
|
代码模式的抽象方式与OOP语言中的代码规范很相似，该类模式有助于解决某种OOP语言中的特定问题。代码模式的主要目标在于：
|
|
|
|
|
|
|
|
|
|
代码模式与具体的程序设计语言或者类库有关，它们主要从语法的角度对于软件系统的结构方面提供一些基本的规范。这些模式对于类的设计不适用，同时也不支持程序员开发和应用框架，命名规范是类库中的名字标准化的基本方法，以免在使用类库时产生混淆。
|
|
|
|
|
|
在应用程序框架“菜谱”（application framework cookbook recipes）中有很多“菜谱条”，它们用一种不很规范的方式描述了如何应用框架来解决特定的问题。程序员将框架作为应用程序开发的基础，特定的框架适用于特定的需求。“菜谱条”通常并不讲解框架的内部设计实现，只讲如何使用。
|
|
|
|
|
|
形式合约（formal contracts）也是一种描述框架设计的方法，强调组成框架的对象间的交互关系。有人认为它是面向交互的设计，对其他方法的发展有启迪作用。但形式化方法由于其过于抽象，而有很大的局限性，仅在小规模程序中使用。
|
|
|
|
|
|
（1）符号所包含的元素很少，并且其中引入的概念能够被映射成为面向对象程序设计语言中的概念。例如，参与者映射成为对象。
|
|
|
|
（2）形式合约中考虑到了复杂行为是由简单行为组成的事实，合约的修订和扩充操作使得这种方法很灵活，易于应用。
|
|
|
|
|
|
（1）在某些情况下很难用，过于繁琐。若引入新的符号，则又使符号系统复杂化。
|
|
|
|
（2）强制性的要求过分精密，从而在说明中可能发生隐患（例如冗余）。
|
|
|
|
（3）形式合约的抽象程度过低，接近OOP语言，不易分清主次。
|
|
|
|
|
|
Erich Gamma在他的博士论文中总结了一系列的设计模式，做出了开创性的工作。他用一种类似分类目录的形式将设计模式记载下来。我们称这些设计模式为设计模式目录。根据模式的目标（所做的事情），可以将它们分成创建性模式（creational）、结构性模式（structural）和行为性模式（behavioral）。创建性模式处理的是对象的创建过程，结构性模式处理的是对象／类的组合，行为性模式处理类和对象间的交互方式和任务分布。根据它们主要的应用对象，又可以分为主要应用于类的和主要应用于对象的。
|
|
|
|
下表是Erich Gamma等人总结的23种设计模式，这些设计模式通常被称为GoF（Gang of Four，四人组）模式。因为这些模式是在Design Patterns:Elements of Reusable Object-Oriented Software中正式提出的，而该书的作者是Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides，这几位作者常被称为“四人组”。
|
|
|
|
|
|
|
|
|
|
|
