|
|
|
本节简单地介绍设计模式的分类，有关各模式的具体实现，请参考专门讨论设计模式的书籍。
|
|
|
|
|
|
Peter Coad从MVC的角度对面向对象系统进行了讨论，设计模式由最底层的构成部分（类和对象）及其关系来区分。他使用了一种通用的方式来描述一种设计模式，将模式划分为以下3类：
|
|
|
|
（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，这几位作者常被称为“四人组”。
|
|
|
|
|
|
|
|
|
|
|
