软件设计师（2024下半年备考学习笔记）

@KAI1

已于 2024-09-26 16:50:00 修改

阅读量474

点赞数 5

文章标签：学习方法

于 2024-09-25 11:47:56 首次发布

本文链接：https://blog.csdn.net/weixin_55209909/article/details/142495593

版权

上午题：综合知识【满分：75分/及格线：45分】

一、软件工程基础知识

1.1 软件开发模型

（1）瀑布模型：适用于软件需求很明确的工程。

（2）原型、演化模型、增量模型：构造简易系统，针对需求不明确的情况。

原型和瀑布模型是互补关系，原型是为了解决用户需求分析难以把控即需求不明确而提出的；该模型，先做出初步模型，然后让用户使用，以便于用户进一步明确自己的需求，是一种抛弃式的模型，因为需求一旦明确就会被抛弃。

演化模型：一种渐进式的原型，即它采取原型的设计模式，但不会将其抛弃，而是在此基础上进一步进行设计。

增量模型：有原型和瀑布模型的思想，是一种递增式设计，将产品一步一步进行设计，每完成一步就交由客户审视，这样也可以使得下一步的设计更为明确；如何进行模块划分是难点所在。

（3）螺旋模型：强调风险分析；综合了瀑布模型和演化模型的优点。

（4）V模型：强调测试。

（5）喷泉模型：面向对象。

（6）RAD模型：能够快速构建业务系统。

（7）构件组装模型(CBSD)：构建软件系统时复用已有的软件“构件”；极大的提高了软件开发当中的复用性，缩短时间、节省成本、增强可靠性。

（8）统一过程模型(UP/RUP)：由用例驱动、以架构为中心、迭代和增量。

1.2 软件开发方法

（一）敏捷开发方法：其特点是快捷，该类方法包括：自适应开发、水晶方法、特征驱动开发、SCRUM、极限编程；该类方法适用于做小型项目；其核心技术是重构（一种重新组织技术，重新审视需求和设计，重新明确的描述他们的需求和现有的需求，可以简化构件的设计而无需改变其功能或行为）

（1）极限编程(XP)特点：测试先行、结对编程、集体代码所有制、持续集成(可以按日甚至按小时为客户提供可运行的版本)、每周工作40个小时。

（2）并列争球法特点：使用迭代的方法，其中把每三十天一次的迭代成为一个冲刺，并按需求的优先级来实现产品，多个自组织和自治小组递增实现产品，并通过简短的日常情况会议进行协调。

（3）水晶法特点：该方法认为每一个不同的项目都需要一套不同的策略、约定和方法论。

（二）结构化方法

（1）结构化法：用户至上；严格区分工作阶段，每阶段有任务和成果；强调系统开发过程的整体性和全局性；系统开发过程工程化，文档资料标准化；自顶向下，逐步分解。

（2）原型法：适用于需求不明确的开发；包括抛弃式原型和演化式原型。

（3）面向对象方法：更好的复用性；关键在于建立一个全面、合理、统一的模型；分析设计实现三个阶段，界限不明确。

（4）面向服务方法：三个主要的抽象级别：操作、服务、业务流程；SOAD分为三个层次：基础设计层（底层服务构件）、应用结构层（服务之间的接口和服务级协定）、业务组织层（业务流程建模和服务流程编排）；服务建模：分为服务发现、服务规约和服务实现。

1.3 需求分析

（一）功能需求：考虑系统要做什么，在何时做，在何时以及如何修改或升级。

（二）性能需求：考虑软件开发的技术性指标，例：存储容量限制、执行速度、响应时间及吞吐量

（三）数据需求：考虑输入输出数据的格式，发送数据的频率，数据的准确性，数据流量，数据需保持的时间

1.4 软件设计

（一）结构化设计的原则：保持模块的大小适中；尽可能减少调用的深度；多扇入，少扇出(上层模块调用自己称之为扇入，自己调用其他模块称之为扇出)；单入口，单出口；模块的作用域应该在模块之内；功能应该是可预测的

（二）概要设计

（1）设计软件系统的总体结构（2）数据结构及数据库设计（3）编写概要设计文档（4）评审

（三）详细设计

（1）对每个模块进行详细的算法设计（2）对模块内的数据结构进行设计

（3）对数据库进行物理设计（4）其他设计（代码设计，输入/输出格式设计，用户界面设计）

（5）编写详细设计说明书（6）评审

（四）内聚与耦合（遵循高内聚低耦合）

（1）内聚（内聚度从高到低）

内聚类型	描述
‌功能内聚	模块内的所有元素共同作用完成一个功能，缺一不可。
顺序内聚‌	一个模块中的各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素的输出就是下一个功能元素的输入。
通信内聚	模块内所有处理元素都在同一个数据结构上。
过程内聚	一个模块完成多个任务，这些任务必须按指定的过程执行。
‌瞬时内聚	有时也称为时间内聚；把需要同时执行的任务或动作组合在一起。
逻辑内聚	模块完成逻辑上相关的一组任务。
偶然内聚	一个模块内的各处理元素之间没有任何联系或有松散的联系。

（2）耦合（耦合度从低到高）

耦合类型	描述
内容耦合	如果一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常入口转到另一个模块内部；或者两个模块有一部分程序代码重迭；或者一个模块有多个入口，则两个模块之间就发生了内容耦合。
公共耦合	若一组模块都访问同一个公共数据。
‌外部耦合‌	通过一个中间媒介进行通信，如全局变量、消息队列等。
‌控制耦合	通过传递控制变量来协调模块间的交互。
标记耦合	通过参数传递一些标志位来影响模块的行为。
数据耦合‌	模块间通过参数传递数据，这是最松散的耦合方式。
非直接耦合	模块间没有任何直接联系，通过外部接口进行通信。

1.5 软件工程质量特性

软件工程质量特性主要包括六个方面：功能性、可靠性、易用性、效率、可维护性和可移植性。‌

（1）功能性‌：软件产品提供满足明确和隐含要求的功能的能力，包括适合性、准确性、互操作性、安全保密性等。

（2）可靠性‌：软件产品在指定条件下使用时，维护规定性能级别的能力，包括成熟性、容错性、易恢复性等。

（3）易用性‌：软件产品被理解、学习、使用和吸引用户的能力，包括易理解性、易学性、易操作性、吸引性等。

（4）效率‌：相对于所用资源的数量，软件产品提供适当性能的能力，包括时间特性、资源利用性等。

（5）可维护性‌：软件产品可被修改的能力，包括易分析性、易改变性、稳定性、易测试性等。

改正性维护：即用户发现bug，然后我就修改bug。
适应性维护：即解决运行平台版本更迭的问题适用数据环境，软件硬件适应。
完善性维护：指在运行过程中发现一些不足，进而对系统的性能等方面进行完善和扩充。
预防性维护：对将来可能导致的问题进行预防工作把需要进行维护的模块进行重构，或者写文档。

（6）可移植性‌：软件产品从一种环境迁移到另外一种环境的能力，包括适应性、易安装性、共存性、易替换性等。

1.6 软件测试

（一）软件测试的原则与类型

1.原则：(1)尽早、不断的进行测试；(2)程序员避免测试自己设计的程序；(3)既要选择有效、合理的数据，也要选择无效、不合理的数据；(4)修改后应进行回归测试(5)尚未发现的错误数量与该程序已发现错误数成正比；（程序A发现30个bug，程序B发现100个bug，修复完成后重点测B）

2.类型：软件测试类型分为动态测试(利用到了计算机的测试)和静态测试(纯手工的测试)

(1)动态测试包括：黑盒测试法(即看不到程序内部，只管输入的是什么，输出的是什么)、白盒测试法(从程序结构方面进行测试)、灰盒测试法（将两者结合起来）

(2)静态测试包括：桌前检查（程序员写完代码自己检查一边）、代码走查（代码人工计算执行一遍）、代码审查（交叉检查）

3.黑盒测试：

（1）等价类划分：即将所有数据类划分为许多个层次，每个数据层次挑选出一个最具代表性的数据进行测试即可

（2）边界值分析：即需要对等价类之间的边界值进行测试(一般是端点、略小于端点的值、略大于端点的值)

（3）错误推测：即自己推测错误的原因，该方法强调经验

4.白盒测试(逻辑覆盖测试)：

（1）语句覆盖测试：即程序中的每一条语句都要进行测试(覆盖度最低的测试)，通过设计n组数据，使其覆盖掉所有的路径。

（2）判定覆盖：即所有判断的真假分支都要测试一遍。

（3）条件覆盖：即在判定时对判定的条件的真假性进行测试。

5.测试阶段

测试阶段可分为四个步骤：单元测试、集成测试、确认测试、系统测试。

单元测试：模块性的测试，即对于一个函数，是否达到了其目的，每个模块的功能是否完善。

集成测试：即模块间的衔接测试，不衔接的模块就将其组装起来，组装方式有两种：一次性组装(一次全部组装)和增量式组装(组装两个模块时测试一下、组装到三个模块时再测试一下…)。

确认测试：即对需求进行确认，测试该程序是否满足需求，测试包括：内部确认测试、Alpha测试(即项目在开发环境进行测试)、Beta测试(即用户在自己的本地计算机自行测试)、验收测试。

系统测试：主要是压力、性能、可靠性的测试，而性能测试包括：负载测试、强度测试(即系统资源缺失的情况下系统能否正常运行)、容量测试，压力测试则是测试同时访问人数的极限。

6.McCabe复杂度（环路复杂度的计算）

计算有向图的环路复杂度：

方法一：V(G)=m-n+2；说明：其中V(G)是有向图G中的环路个数，m是G中的有向弧数(边数)，n是G中的节点数(点数)。

方法二：V(G)=m+1；说明：为闭合环路数/判定结点的数目。

上图的的环路复杂度为：

（1）V(G)=m-n+2=8-1+2=3

（2）V(G)=m+1=2+1=3

1.7 能力成熟度模型（CMM）和能力成熟度模型集成（CMMI）

（一）能力成熟度模型（CMM）：对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。

一级：初始级；杂乱无章，甚至混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。

二级：可重复级；建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。

三级：已定义级；管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准过程。

四级：已管理级；制定了软件过程和产品质量的详细度量标准。

五级：优化级；加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

CMM 的五个级别由浅入深，逐渐成熟，使得整个过程不断改进，循序渐进。

（二）能力成熟度模型集成（CMMI）：CMMI 是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，提高过程质量和效率；CMMI 提供了两种表示方法，阶段式模型和连续式模型。

阶段式模型：结构类似于 CMM，关注组织的成熟度，有五个成熟度等级。

初始级：过程不可预测且缺乏控制。
已管理级：过程为项目服务。
已定义级：过程为组织服务。
定量管理级：过程已度量和控制。
优化级：集中于过程改进。

连续式模型：关注每个过程域的能力，有六个等级。

CL0（未完成的）：未执行或未得到目标。
CL1（已执行的）：可标识的输入工作产品转换成可标识的输出工作产品。
CL2（已管理的）：已管理的过程的制度化。
CL3（已定义的）：已定义的过程的制度化。
CL4（定量管理的）：可定量管理的过程的制度化。
CL5（优化的）：量化（统计学）手段改变和优化过程域。

1.8 Pert图与Gantt图

（一）Pert图

最早时刻：从开头开始计算，一般首结点的开始时间为0，最早时刻为前驱最早时刻+路径上的时间=该结点最早时刻，如果遇到多个箭头指向一个结点(例如:5结点和6结点同时指向8,入度为2)，即入度为n，则他的最早时刻取最大的那个值。

（1）入度为1:对于结点2来说，它只有一个入度他的前驱结点是1，又因为首结点的最早开始时刻为0，所以2结点的最早时刻为0+2=2；相对于3来说，他的前驱结点是2，他的最早时刻为2，完成该任务的时间为4(就是路径上的数字)，所以3的最早时刻为6

（2）入度为n:对于结点8来说，他的入度为2，如果计算他的最早时刻，取计算值为最大的那个，如下图，计算8结点时，一个是12，另一个是14，14大于12，所以最后8的开始结点为14

最晚时刻：从末尾往前推，首先要把最早时刻的尾结点的最早时刻计算出来，然后另尾结点的最早时刻和最晚时刻相等。于是尾结点的最迟时刻就有了，然后就可以依次往前推，如果遇到多个结点对应一个结点(例如3节点和4结点同时指向2)取最小的那个

松弛时间：就是不耽误任务按照如期时间完成，可以摸鱼的时间，计算方式，对于某个结点来说，他的最早时刻和最晚时刻不相同，他俩相减就是松弛时间，但是也有特殊情况，就是一个结点对应两个结点，对于一个结点来说，那个时间刚好完成任务，但是对于另一个结点来说，从这个时刻开始，还有多余的时间用来摸鱼(例如4结点到6结点和7结点)，这样的可以分别计算。

关键路径：就是为了不耽误工期，即松弛时间为0的那一条路径:如图所示，关键路径为1–>2–>4–>6–>8–>10–>11

（二）Gantt图

Gantt图，其最为直观的特点是简洁明了，可以很清楚的看到计划的开展，缺点是不能看出任务间的逻辑关系，无法看出哪个任务先做，哪个任务后做。

1.9 项目质量管理

知识领域	描述
时间管理	确定项目的时间安排和进度，确保项目在规定时间内完成。
风险管理	识别、分析和应对项目风险，确保项目能够应对潜在的风险。风险：指“损失或伤害的可能性”，风险可以分为项目风险(由项目经理主导控制的)和技术风险以及商业风险（超出项目经理控制的）；特点是关心未来、关心变化、关心选择。风险曝光度：（风险出现的概率乘以风险可能造成的损失）；风险曝光度常用于风险的管控。
整合管理	用于整合各个项目管理过程的活动，确保项目目标能够实现。
范围管理	确保项目范围的确定、变更和控制，以满足项目目标。
成本管理	确定项目成本和预算，监控和控制项目的成本，确保项目在预算范围内完成。
质量管理	确定项目质量标准和要求，确保项目交付物符合质量要求。
人力资源管理	确定项目所需人力资源，管理团队的组建、培训和绩效评估。
通信管理	制定项目的沟通计划，确保项目成员之间的有效沟通和信息传递。
采购管理	确定项目所需的采购资源，进行供应商选择和管理，确保项目所需资源的供应。
相关方管理	识别和管理项目相关方，进行相关方的沟通、参与和管理，以满足相关方的需求和期望。

1.10 软件项目估算

常用的估算方法有三种：基于已经完成的类似项目进行估算、基于分解技术进行估算(分解技术包括问题分解和过程分解)、基于经验估算模型(IBM模型、COCOMO模型、Putnam模型)

COCOMO：该模型按其详细程度分为基本、中级、详细COCOMO模型

（1）基本：该模型是一个静态单变量模型，用于对整个软件系统进行估算

（2）中级：该模型时一个静态多变量模型，将软件系统模型分为了系统和部件两个层次，系统由部件构成

（3）详细：将软件系统模型分为系统、子系统和模块三个层次

注：COCOMOII模型在模型层次结构中有三种不同的规模估算选择：对象点、功能点和代码行

二、面向对象

2.1 面向对象基本概念

面向对象（Object- Oriented，OO）方法是一种非常实用的系统化软件开发方法，他以客观世界中的对象为中心，其分析设计思想符合人们的思维方式，分析和设计的结果与客观世界的实际比较接近。

面向对象=对象（Object）+分类（Classification）+继承（Inheritance）+通过消息的通信（Communication with Messages）

对象：一个对象把属性和行为封装为一个整体。
消息：对象之间进行通信的一种构造叫做消息。
类：一个类定义了一组大体上相似的对象。
继承：继承是父类和子类之间共享数据和方法的机制。
多态：在收到消息时，对象要予以响应。不同的对象收到同一消息可以产生不同结果，这一现象称为多态。
动态绑定：绑定是一个把过程调用和相应调用需要执行的代码加以结合的过程。动态绑定是和类的继承以及多态相联系的，当一个对象发送消息请求服务时，要根据接收对象的具体情况将请求的操作与实现的方法进行连接，即动态绑定。

面向对象的特性：继承、封装、多态

（一）封装：一个对象把属性和行为封装为一个整体；是一种信息隐蔽技术。

1.封装就是将类的某些信息隐藏在类内部，不允许外部程序直接访问，而是通过该类提供的方法（getter和setter）来实现对隐藏信息的操作和访问。

2.封装的目的：使对象的使用者和生产者分离。

3.封装的步骤：

（1）使用关键字private对类的属性进行隐藏；（方法一般不用隐藏）

（2）利用setter/getter方法对属性值进行操作；

（3）可以在方法中加入条件控制语句，进行限制。

在使用setter方法的时候，可以发现this关键字，这是由于方法的变量名和属性名是一样的，局部变量名和成员变量名会优先使用局部变量名，this就是解决这种情况的办法。

（二）继承

继承：子类和父类之间，共享属性和方法。

父类：称为超类、基类；子类：扩展类、派生类。

在定义和实现一个类的时候（子类），可以在一个已经存在的类的基础上进行（父类）。

一个父类可以有多个子类，这些子类都是父类的特例，如：交通工具（父类）、飞机（子类）。

父类描述了子类的公共属性和方法。一个子类可以继承它的父类的所有属性和方法，这些属性和方法在子类中不必定义，子类还可以定义自己的属性和方法。

【注意】：子类无法访问父类的private字段或者private方法！

继承的分类：

单重继承：子类B只能从一个父类A中得到继承；
多重继承：一个子类可以有不止一个父类。

java只允许单继承！

子类可以重写（覆盖）继承来自父类的方法，即方法名、参数列表与父类的方法相同，但实现方式不同。

子类可以继承父类，所有的属性、方法；
子类可以新增自己的属性、方法；
子类可以重写（覆盖）父类的方法。

方法的重载overLoad和重写overRide
Override和Overload不同的是，如果方法签名不同，就是Overload，Overload方法是一个新方法；如果方法签名相同，并且返回值也相同，就是Override。

（三）多态

收到消息时，对象要予以响应。不同的对象，收到同一消息可以产生完全不同的结果。这一现象称为：多态。

使用多态时，用户可以发送一个通用的消息，而实现的细节由接受对象自行决定。

多态的实现，收到继承的支持，利用类的继承的层次关系，把具有通用功能的消息放在高层次，不同的实现这一功能的行为，放在低层次。

2.2 面向对象程序设计与分析

（一）面向对象程序设计（Object- Oriented Programming，OOP）的实质是选用一种面向对象程序设计语言，采用对象、类及相关概念进行的程序设计。

类：类具有实例化的功能，包括生成实例和消除实例。同一个类的不同实例具有相同的数据结构，承受的是同一方法集合所定义的操作；同一个类的不同实例可以持有不同值，因而具有不同状态；

实例的初始状态可以在实例化时确定。

（二）面向对象设计原则

单一职责原则 : 设计目的单一的类。
开放-封闭原则 : 对扩展开放,对修改封闭。
李氏(Liskov)替换原则 : 子类可以替换父类。
依赖倒置原则 : 要依赖于抽象,而不是具体实现;针对接口编程,不要针对实现编程。
接口隔离原则 : 使用多个专门的接口比使用单一的总接口要好。
组合重用原则 : 要尽量使用组合,而不是继承关系达到重用目的。
迪米特(Demeter)原则(最少知识法则) : 一个对象应当对其他对象有尽可能少的了解。

（三）面向对象分析

（1）面向对象的分析包括3个步骤: 第1步是用例建模，它决定了如何由产品得到各项计算结果；并以用例图和相关场景的方式展现出来；第2步是类建模，它决定了类及其属性，然后确定类之间的关系和交互；第3步是动态建模，它决定了类或每个子类的行为，并以状态图的形式进行表示。

（2）面向对象分析包含5个活动:认定对象、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信恙。

（3）面向对象分析主要回答软件系统需要解决什么问题，在面向对象分析阶段并不考虑系统实现以及系统的测试问题，强调建立独立于系统实现的系统分析模型，其关注点仍然侧重于问题域。

2.3 UML

（一）事物

UML有四种事物：结构事物、行为事物、分组事物和注释事物

结构事物：结构事物是UML模型中的名词。通常是模型的静态部分，描述概念或物理元素。

行为事物：行为事物是UML的动态部分。是模型中的动词，描述了跨越时间和空间的行为。

分组事物：分组事物是UML的组织部分。

注释事物：注释事物是UML的解释部分。

（二）关系

UML中有四种关系：依赖、关联、泛化和实现

依赖：依赖是两个事物间的语义关系，其中一个事物发生变化会影响另一个事物。在图形上，把一个依赖化成一条可能有方向的虚线。

关联：关联是一种结构关系，它描述了一组链，链是对象之间的连接，聚集是一种特殊类型的关联，描述了整体和部分间的结构关系。

泛化：泛化是一种特殊/一般关系，特殊元素的对象可替代一般元素的对象。

实现：两种情况下会使用实现关系：在接口实现它们的类或构件关系；在用例和实现他们的协作之间。

泛化：类与类之间的继承关系（一般从子类指向父类）

关联：两个类或类于接口的依赖关系

聚合：关联的特例，整体与部分，拥有的关系，可分离，有各自的生命周期

组合：强于聚合，不可分离，是一个整体

（三）UML图

（1）类图展现了一组对象、接口、协作和他们之间的关系，通常包括：类、接口。

协作，依赖、泛化和关联关系。

（2）对象图：展现了某一时刻一组对象以及他们之间的关系，描述了在类图中所建立的事物的实例的静态快照

用例图：展现了一组用例、参与者以及他们之间的关系。用例间的扩展关系（extend）和包含关系（include）

交互图：一张交互图表现的是一个交互，由一组对象和它们之间的关系组成，包含他们之间可能传递的消息。交互图表现为序列图、通信图、交互概念图和计时图。序列图强调消息的时间顺序，通信是强调接收和发送消息的对象的结构组织，交互概览图强调控制流

状态图：展现了一个状态机，由状态、转换、事件和活动组成。强调对象行为的时间顺序。

活动图：活动图是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程。

插件图：展现了一组构件之间的组织和依赖

2.4 设计模式

（一）设计模式

（二）创建型设计模式

（1）抽象工厂（Abstract Factory）：定义一个接口用于创建相关或有依赖关系的对象族，无需明确具体类。适用于一个系统要独立于它的产品的创建、组合和表示。

（2）生成器（Builder）：封装一个复杂对象的构造过程，并允许按步骤构造。适用于创建复杂对象的算法应该独立于该对象组成部分以及他们的装配方式时。

（3）工厂方法（Factory Method）：定义一个创建对象的抽象方法，由子类决定要实例化的对象。适用于当一个类不知道他所必需创建的对象的类时。

（4）原型（Prototype）：无需知道相应类的信息。适用于当一个系统应该独立于它的产品创建时。

（5）单例（Singleton）：确保一个类最多只有一个实例，并提供一个全局访问点。

（三）结构型设计模式

（1）适配器（Adapter）：类接口转换成期望的另一个接口。适用于想使用一个已经存在的类，但接口不符合要求。

（2）桥接（Bridge）：将抽象部分与他的实现部分分离，可独自变化。

（3）组合（Composite）：将对象组合成树状的层次结构模式，使用户对单个对象有一致访问性。

（4）装饰（Decorator）：动态的将新功能附加到对象上。

（5）外观（Facade）：隐藏了系统复杂性，向客户端提供一个接口

（6）享元（Flyweight）：通过共享高效的支持大量细粒度的对象。适用于一个程序使用；大量对象

（7）代理（Proxy）：由代理对象控制原对象的引用。适用于需要复杂对象代替简单指针的时候

（四）行为型模式

（1）责任链模式（Chain of Responsibility）
        意图：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

        适用性：有多个对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定；想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求；可处理一个请求的对象集合应被动态指定。

（2）命令模式（Command）
        意图：将请求封装为一个对象，从而使得可以用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。

        适用性：抽象出待执行的动作以参数化某对象；在不同的时刻指定、排列和执行请求；支持取消操作；支持修改日志；用构建在原语操作上的高层操作构造一个系统。

（3）解释器模式（Interpreter）
        意图：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

        适用性：该文法简单；效率不是一个关键问题。

（4）迭代器模式（Iterator）
        意图：提供一种方法顺序访问一个聚合对象中的各个元素，且不需要暴露该对象的内部表示。

        适用性：访问一个聚合对象的内容而无须暴露它的内部表示；支持对聚合对象的多种遍历；为遍历不同的聚合结构提供一个统一的接口。

（5）中介者模式（Mediator）
        意图：用一个中介对象来封装一系列的对象交互。使各对象不需要显式地相互引用，从而使耦合松散，而且可以独立地改变它们之间的交互。

        适用性：一组对象以定义良好但是复杂的方式进行通信，产生的相互依赖关系结构混乱且难以理解；一个对象引用其他很多对象并且直接与这些对象通信，导致难以复用该对象；想定制一个分布在多个类中的行为，而又不想生成太多的子类。

（6）备忘录模式（Memento）
        意图：在不破坏封装性的前提下，捕获一个对象的内部状态，并在对象之外保存这个状态。这样以后就可以将对象恢复到原先保存的状态。

        适用性：必须保存一个对象在某一时刻的状态，这样以后需要时它才能恢复到先前的状态；如果一个用接口来让其他对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。

（7）观察者模式（Observer）
        意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都能得到通知，并被自动更新。

        适用性：当一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两者封装在独立的对象中以使它们可以各自独立地改变和复用；当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变时；当一个对象必须通知其他对象，而它又不能假定其他对象是谁，即不希望这些对象是紧耦合的。

（8）状态模式（State）
        意图：允许一个对象在其内部状态改变时改变它的行为。

        适用性：一个对象的行为决定于它的状态，并且它必须在运行时根据状态改变它的行为；一个操作中含有庞大的多分支的条件语句，且这些分支依赖于该对象的状态。

（9）策略模式（Strategy）
        意图：定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。

        适用性：许多相关的类仅仅是行为有异；需要使用一个算法的不同变体；算法使用客户不应该知道的数据；一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现，将相关的条件分支移入它们各自的Strategy类中，以代替这些条件语句。

（10）模板方法（Template Method）
        意图：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

        适用性：一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现；各子类中公共的行为应被提取出来，并集中到一个公共父类中，以避免代码重复；控制子类扩展。

（11）访问者模式（Visitor）
        意图：标识一个作用于某对象结构中的各元素的操作，它允许在不改变各元素的类的前提下定义作用于这些元素的新操作。

        适用性：一个对象结构包含很多类对象，它们有不同的接口，而用户想对这些对象实施一些依赖于其具体类的操作；需要对一个对象结构中的对象进行很多不同的、不相关的操作，又想避免这些操作“污染”这些对象的类；定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。