软件体系结构与设计模式笔记
软件体系结构与设计模式笔记
第1章软件体系结构概述
ü SEI软件体系结构讨论群定义如下：一个程序/系统构件的结构，它们之间的相互关系，以及在设计和交付的整个过程中的原则和指导方针。
ü Mary Shaw和David Garlan认为软件体系结构包括构成系统的设计元素的描述，设计元素的交互，设计元素组合的模式，以及在这些模式中的约束。
ü 软件体系结构包括构件(Component)、连接件(Connector)和约束(Constrain)或配置(Configuration)三大要素。
ü 国内普遍接受的定义：软件体系结构包括构件、连接件和约束，它是可预制和可重构的软件框架结构。
ü 构件是可预制和可重用的软件部件，是组成体系结构的基本计算单元或数据存储单元
ü 连接件也是可预制和可重用的软件部件，是构件之间的连接单元
ü 构件和连接件之间的关系用约束来描述
ü 软件体系结构 = 构件 + 连接件 + 约束
软件体系结构的优势容易理解、重用、控制成本、可分析性
第2章软件体系结构风格
w 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。
w 体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
w 体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。
w 数据流风格: 批处理序列; 管道/过滤器。
w 调用/返回风格：主程序/子程序；面向对象风格；层次结构。
w 独立构件风格：进程通讯；事件系统。
w 虚拟机风格：解释器；基于规则的系统。
w 仓库风格：数据库系统；超文本系统；黑板系统。
w 过程控制环路
w C/S风格体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。
w B/S风格浏览器/Web服务器/数据库服务器。
优点：C/S体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。
缺点：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一，使用繁杂不利于推广使用、软件移植困难、软件维护和升级困难、新技术不能轻易应用
优点：基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。
缺点：B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
B/S体系结构的系统扩展能力差，安全性难以控制。
采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远低于C/S体系结构。
B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。
第3章软件需求与架构
w 需求的基本概念
ü IEEE (1997)
Ø (1) 用户解决问题或达到目标所需的条件或能力
Ø (2) 系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力
Ø (3) 一种反映上面（1）或（2）所描述的条件或能力的文档说明
w 业务需求
ü 反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求
w 用户需求
ü 描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。
w 系统需求
ü 从系统的角度来说明软件的需求，包括用特性说明的功能需求、质量属性，以及其他非功能需求，还有设计约束等。
w 非功能需求
ü 指产品必须具备的属性或品质，如正确性、可靠性、性能、容错性和可扩展性等。
w 功能需求
ü 需求的主体，需求的本质
ü 功能需求定义：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作
w 设计约束
w 获取需求的方法
ü 面谈（访谈）
ü 问卷调查
ü 会议（需求讨论会、重点问题讨论会、业务专题讨论会、设计专题讨论会）
ü 文档研究
ü 任务示范（观察）
ü 用例与角色扮演
ü 原型设计（小规模试验）研究类似公司
w 需求的层次化
ü 业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。
ü 用户级需求：用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？
ü 开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？
w 需求分类
ü 功能需求：更多体现各级直接目标要求
ü 质量属性：运行期质量 + 开发期质量
ü 约束需求：业务环境因素 +使用环境因素 + 构建环境因素+ 技术环境因素
ü 功能模型——如UC
ü 业务流程模型——如DFD
ü 数据建模模型——如ER
w 用例建模（Use CaseModeling）是使用用例的方法来描述系统的功能需求的过程，用例建模促进并鼓励了用户参与，这是确保项目成功的关键因素之一。
w 粒度原则：
w 用例要有路径，路径要有步骤。而这一切都是“可观测”的。
ü 需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。
w 外部质量对于用户而言是可见的包括正确性、健壮性、可靠性、性能、安全性、易用性、兼容性等。
w 内部质量只有开发人员关心它们可以帮助开发人员实现外部质量包括易理解性、可测试性、可维护性、可扩展性、可移植性、可复用性等
ü 依赖注入
w 构造注入(Constructor Injection)：通过构造函数注入实例变量。
w 设值注入(Setter Injection)：通过Setter方法注入实例变量。
w 接口注入(Interface Injection)：通过接口方法注入实例变量。
1. 用例文档
w 用例编号
w 用例名
w 执行者
w 前置条件
w 后置条件
w 涉众利益
w 基本路径
ü 1…..××××
ü 2……××××
ü 3…..××××
2. 需求规格说明书
第1章_统一建模语言基础知识
a) 视图(View)
i. 用户视图：以用户的观点表示系统的目标，它是所有视图的核心，该视图描述系统的需求。
ii. 结构视图：表示系统的静态行为，描述系统的静态元素，如包、类与对象，以及它们之间的关系。
iii. 行为视图：表示系统的动态行为，描述系统的组成元素如对象在系统运行时的交互关系。
iv. 实现视图：表示系统中逻辑元素的分布，描述系统中物理文件以及它们之间的关系。
v. 环境视图：表示系统中物理元素的分布，描述系统中硬件设备以及它们之间的关系。
用例图(Use Case Diagram): 又称为用况图，对应于用户视图。在用例图中，使用用例来表示系统的功能需求，用例图用于表示多个外部执行者与系统用例之间以及用例与用例之间的关系。用例图与用例说明文档(Use Case Specification)是常用的需求建模工具，也称之为用例建模。
类图(Class Diagram)：对应于结构视图。类图使用类来描述系统的静态结构，类图包含类和它们之间的关系，它描述系统内所声明的类，但它没有描述系统运行时类的行为。
w 类之间的关系
ü 关联关系
• 关联关系(Association)是类与类之间最常用的一种关系，它是一种结构化关系，用于表示一类对象与另一类对象之间有联系。
• 双向关联
• 单向关联
• 自关联
• 重数性关联
ü 聚合关系
• 聚合关系(Aggregation)表示一个整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构，从而找出一些成员类，该整体类和成员类之间就形成了聚合关系。
ü 组合关系
• 组合关系(Composition)也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在，部分对象与整体对象之间具有同生共死的关系。
ü 依赖关系
• 依赖关系(Dependency)是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物，在需要表示一个事物使用另一个事物时使用依赖关系。大多数情况下，依赖关系体现在某个类的方法使用另一个类的对象作为参数。
ü 泛化关系
• 泛化关系(Generalization)也就是继承关系，也称为“is-a-kind-of”关系，泛化关系用于描述父类与子类之间的关系，父类又称作基类或超类，子类又称作派生类。在UML中，泛化关系用带空心三角形的直线来表示。
ü 接口与实现关系
• 接口之间也可以有与类之间关系类似的继承关系和依赖关系，但是接口和类之间还存在一种实现关系(Realization)，在这种关系中，类实现了接口，类中的操作实现了接口中所声明的操作。在UML中，类与接口之间的实现关系用带空心三角形的虚线来表示。
w 顺序图定义
ü 顺序图(SequenceDiagram)是一种强调对象间消息传递次序的交互图，又称为时序图或序列图。
w 状态图定义
ü 状态图(StatechartDiagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。
第2章_面向对象设计原则
w 单一职责原则要求在软件系统中，一个类只负责一个功能领域中的相应职责。
w 开闭原则要求一个软件实体应当对扩展开放，对修改关闭，即在不修改源代码的基础上扩展一个系统的行为。
w 里氏代换原则可以通俗表述为在软件中如果能够使用基类对象，那么一定能够使用其子类对象。
w 依赖倒转原则要求抽象不应该依赖于细节，细节应该依赖于抽象；要针对接口编程，不要针对实现编程。
w 接口隔离原则要求客户端不应该依赖那些它不需要的接口，即将一些大的接口细化成一些小的接口供客户端使用。
w 合成复用原则要求复用时尽量使用对象组合，而不使用继承。
w 迪米特法则要求一个软件实体应当尽可能少的与其他实体发生相互作用。
第3章_设计模式概述
w 设计模式的定义
ü 设计模式(DesignPattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
ü 设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式，其中的关键元素包括以下四个方面：
w 模式名称(Pattern name)
w 问题(Problem)
w 解决方案(Solution)
w 效果(Consequences)
| 范围\目的 |
创建型模式 |
结构型模式 |
行为型模式 |
| 类模式 |
工厂方法模式 |
（类）适配器模式 |
解释器模式 模板方法模式 |
| 对象模式 |
抽象工厂模式 建造者模式 原型模式 单例模式 |
（对象）适配器模式 桥接模式 组合模式 装饰模式 外观模式 享元模式 代理模式 |
职责链模式 命令模式 迭代器模式 中介者模式 备忘录模式 观察者模式 状态模式 策略模式 访问者模式 |
第4章_简单工厂模式
ü 简单工厂模式(SimpleFactory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
ü 重构后的代码：
public abstract class AbstractPay
{
public abstract void pay();
}
public class CashPay extends AbstractPay
{
public void pay()
{
//现金支付处理代码
}
}
public class PayMethodFactory
{
public static AbstractPay getPayMethod(String type)
{
if(type.equalsIgnoreCase("cash"))
{
return new CashPay(); //根据参数创建具体产品
}
elseif(type.equalsIgnoreCase("creditcard"))
{
return new CreditcardPay(); //根据参数创建具体产品
}
……
}
}
ü 简单工厂模式最大的缺点是当有新产品要加入到系统中时，必须修改工厂类，加入必要的处理逻辑，这违背了“开闭原则”。
ü 简单工厂模式最大的优点在于实现对象的创建和对象的使用分离，将对象的创建交给专门的工厂类负责，但是其最大的缺点在于工厂类不够灵活，增加新的具体产品需要修改工厂类的判断逻辑代码，而且产品较多时，工厂方法代码将会非常复杂。
ü 简单工厂模式适用情况包括：工厂类负责创建的对象比较少；客户端只知道传入工厂类的参数，对于如何创建对象不关心。
第5章_工厂方法模式
ü 工厂方法模式(FactoryMethod Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(PolymorphicFactory)模式，它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象的公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具体产品类。
ü 抽象工厂类代码：
public abstract class PayMethodFactory
{
public abstract AbstractPay getPayMethod();
}
ü 具体工厂类代码：
public class CashPayFactory extendsPayMethodFactory
{
public AbstractPay getPayMethod()
{
return new CashPay();
}
}
ü 客户类代码片段：
PayMethodFactory factory;
AbstractPay payMethod;
factory=new CashPayFactory();
payMethod =factory.getPayMethod();
payMethod.pay();
ü 工厂方法模式的主要优点是增加新的产品类时无须修改现有系统，并封装了产品对象的创建细节，系统具有良好的灵活性和可扩展性；其缺点在于增加新产品的同时需要增加新的工厂，导致系统类的个数成对增加，在一定程度上增加了系统的复杂性。符合开闭原则。
ü 工厂方法模式适用情况包括：一个类不知道它所需要的对象的类；一个类通过其子类来指定创建哪个对象；将创建对象的任务委托给多个工厂子类中的某一个，客户端在使用时可以无须关心是哪一个工厂子类创建产品子类，需要时再动态指定。
第6章_抽象工厂模式
ü 抽象工厂模式(AbstractFactory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象创建型模式。
ü 具体工厂类的典型代码如下：
public class ConcreteFactory1 extendsAbstractFactory
{
public AbstractProductA createProductA()
{
return new ConcreteProductA1();
}
public AbstractProductB createProductB()
{
return new ConcreteProductB1();
}
}
ü 抽象工厂模式的主要优点是隔离了具体类的生成，使得客户并不需要知道什么被创建，而且每次可以通过具体工厂类创建一个产品族中的多个对象，增加或者替换产品族比较方便，增加新的具体工厂和产品族很方便；主要缺点在于增加新的产品等级结构很复杂，需要修改抽象工厂和所有的具体工厂类，对“开闭原则”的支持呈现倾斜性。
ü 抽象工厂模式适用情况包括：一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节；系统中有多于一个的产品族，而每次只使用其中某一产品族；属于同一个产品族的产品将在一起使用；系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。
第9章_单例模式
ü 单例模式(SingletonPattern)：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。
ü 单例模式的要点有三个：一是某个类只能有一个实例；二是它必须自行创建这个实例；三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。
ü 单例模式的实现代码如下所示：
public class Singleton
{
privatestatic Singleton instance=null; //静态私有成员变量
//私有构造函数
privateSingleton()
{
}
//静态公有工厂方法，返回唯一实例
publicstatic Singleton getInstance()
{
if(instance==null)
instance=new Singleton();
returninstance;
}
}
ü 单例模式的主要优点在于提供了对唯一实例的受控访问并可以节约系统资源；其主要缺点在于因为缺少抽象层而难以扩展，且单例类职责过重。
ü 单例模式适用情况包括：系统只需要一个实例对象；客户调用类的单个实例只允许使用一个公共访问点。
ü 饿汉式单例与懒汉式单例类比较
ü 饿汉式单例类在自己被加载时就将自己实例化。单从资源利用效率角度来讲，这个比懒汉式单例类稍差些。从速度和反应时间角度来讲，则比懒汉式单例类稍好些。
ü 懒汉式单例类在实例化时，必须处理好在多个线程同时首次引用此类时的访问限制问题，特别是当单例类作为资源控制器，在实例化时必然涉及资源初始化，而资源初始化很有可能耗费大量时间，这意味着出现多线程同时首次引用此类的机率变得较大，需要通过同步化机制进行控制。
第10章_适配器模式
ü 适配器模式(AdapterPattern) ：将一个接口转换成客户希望的另一个接口，适配器模式使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。
ü 典型的类适配器代码：
public class Adapter extendsAdaptee implements Target
{
publicvoid request()
{
specificRequest();
}
}
ü 典型的对象适配器代码：
public class Adapter extends Target
{
privateAdaptee adaptee;
publicAdapter(Adaptee adaptee)
{
this.adaptee=adaptee;
}
publicvoid request()
{
adaptee.specificRequest();
}
}
类适配器
对象适配器
ü 适配器模式的主要优点是将目标类和适配者类解耦，增加了类的透明性和复用性，同时系统的灵活性和扩展性都非常好，更换适配器或者增加新的适配器都非常方便，符合“开闭原则”；类适配器模式的缺点是适配器类在很多编程语言中不能同时适配多个适配者类，对象适配器模式的缺点是很难置换适配者类的方法。
ü 适配器模式适用情况包括：系统需要使用现有的类，而这些类的接口不符合系统的需要；想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类一起工作。
第14章_外观模式
ü 外观模式(FacadePattern)：外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。
外观模式也是“迪米特法则”
ü 典型的外观角色代码：
public class Facade
{
private SubSystemA obj1 =new SubSystemA();
private SubSystemB obj2 =new SubSystemB();
private SubSystemC obj3 =new SubSystemC();
public void method()
{
obj1.method();
obj2.method();
obj3.method();
}
}
w 外观模式主要优点在于对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易，它实现了子系统与客户之间的松耦合关系，并降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程；其缺点在于不能很好地限制客户使用子系统类，而且在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。
w 外观模式适用情况包括：要为一个复杂子系统提供一个简单接口；客户程序与多个子系统之间存在很大的依赖性；在层次化结构中，需要定义系统中每一层的入口，使得层与层之间不直接产生联系。
第16章_代理模式
ü 代理模式(ProxyPattern) ：给某一个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式的英文叫做Proxy或Surrogate，它是一种对象结构型模式。
ü 典型的代理类实现代码：
public class Proxy implements Subject
{
private RealSubjectrealSubject = new RealSubject();
public void preRequest()
{…...}
public void request()
{
preRequest();
realSubject.request();
postRequest();
}
public void postRequest()
{……}
}
ü 代理模式的优点在于能够协调调用者和被调用者，在一定程度上降低了系统的耦合度；其缺点在于由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢，并且实现代理模式需要额外的工作，有些代理模式的实现非常复杂。
ü 模式适用环境
ü 根据代理模式的使用目的，代理模式有以下几种类型（续）：
ü 保护(Protect or Access)代理：控制对一个对象的访问，可以给不同的用户提供不同级别的使用权限。
ü 缓冲(Cache)代理：为某一个目标操作的结果提供临时的存储空间，以便多个客户端可以共享这些结果。
ü 防火墙(Firewall)代理：保护目标不让恶意用户接近。
ü 同步化(Synchronization)代理：使几个用户能够同时使用一个对象而没有冲突。
ü 智能引用(Smart Reference)代理：当一个对象被引用时，提供一些额外的操作，如将此对象被调用的次数记录下来等。
第23章_观察者模式
ü 观察者模式(ObserverPattern)：定义对象间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式又叫做发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。观察者模式是一种对象行为型模式。
ü 典型的抽象目标类代码如下所示：
import java.util.*;
public abstract class Subject
{
protectedArrayList observers = new ArrayList();
publicabstract void attach(Observer observer);
publicabstract void detach(Observer observer);
publicabstract void notify();
}
ü 典型的具体目标类代码如下所示：
public class ConcreteSubject extendsSubject
{
publicvoid attach(Observer observer)
{
observers.add(observer);
}
publicvoid detach(Observer observer)
{
observers.remove(observer);
}
publicvoid notify()
{
for(Objectobs:observers)
{
((Observer)obs).update();
}
}
}
ü 典型的抽象观察者代码如下所示：
public interface Observer
{
publicvoid update();
}
ü 典型的具体观察者代码如下所示：
public class ConcreteObserver implementsObserver
{
publicvoid update()
{
//具体更新代码
}
}
ü 客户端代码片段如下所示：
Subject subject = new ConcreteSubject();
Observer observer = new ConcreteObserver();
subject.attach(observer);
subject.notify();
w 观察者模式的主要优点在于可以实现表示层和数据逻辑层的分离，并在观察目标和观察者之间建立一个抽象的耦合，支持广播通信；其主要缺点在于如果一个观察目标对象有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间，而且如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
w 观察者模式适用情况包括：一个抽象模型有两个方面，其中一个方面依赖于另一个方面；一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变；一个对象必须通知其他对象，而并不知道这些对象是谁；需要在系统中创建一个触发链。
ü 组合模式(CompositePattern)：组合多个对象形成树形结构以表示“整体-部分”的结构层次。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致性。
ü Composite Pattern: Compose objects into tree structures to representpart-whole hierarchies. Composite lets clients treat individual objects andcompositions of objects uniformly.
ü 组合模式的主要优点在于可以方便地对层次结构进行控制，客户端调用简单，客户端可以一致的使用组合结构或其中单个对象，用户就不必关心自己处理的是单个对象还是整个组合结构，简化了客户端代码；其缺点在于使设计变得更加抽象，且增加新构件时可能会产生一些问题，而且很难对容器中的构件类型进行限制。
ü 组合模式适用情况包括：需要表示一个对象整体或部分层次；让客户能够忽略不同对象层次的变化，客户端可以针对抽象构件编程，无须关心对象层次结构的细节；对象的结构是动态的并且复杂程度不一样，但客户需要一致地处理它们。
ü 命令模式(CommandPattern)：将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。
ü Command Pattern: Encapsulate a request as an object, thereby lettingyou parameterize clients with different requests, queue or log requests, andsupport undoable operations.
ü 命令模式的主要优点在于降低系统的耦合度，增加新的命令很方便，而且可以比较容易地设计一个命令队列和宏命令，并方便地实现对请求的撤销和恢复；其主要缺点在于可能会导致某些系统有过多的具体命令类。
ü 命令模式适用情况包括：需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互；需要在不同的时间指定请求、将请求排队和执行请求；需要支持命令的撤销操作和恢复操作；需要将一组操作组合在一起，即支持宏命令。
ü 迭代器模式(IteratorPattern) ：提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示，其别名为游标(Cursor)。迭代器模式是一种对象行为型模式。
ü Iterator Pattern: Provide a way to access the elements of an aggregateobject sequentially without exposing its underlying representation.
ü 迭代器模式的主要优点在于它支持以不同的方式遍历一个聚合对象，还简化了聚合类，而且在同一个聚合上可以有多个遍历；其缺点在于增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
ü 迭代器模式适用情况包括：访问一个聚合对象的内容而无须暴露它的内部表示；需要为聚合对象提供多种遍历方式；为遍历不同的聚合结构提供一个统一的接口。
ü 模板方法模式(TemplateMethod Pattern)：定义一个操作中算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法是一种类行为型模式。
ü Template Method Pattern: Define the skeleton of an algorithm in anoperation, deferring some steps to subclasses. Template Method lets subclassesredefine certain steps of an algorithm without changing the algorithm'sstructure.
ü 模板方法模式的优点在于在子类定义详细的处理算法时不会改变算法的结构，实现了代码的复用，通过对子类的扩展可以增加新的行为，符合“开闭原则”；其缺点在于需要为每个不同的实现都定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象
ü 模板方法模式适用情况包括：一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现；各子类中公共的行为应被提取出来并集中到一个公共父类中以避免代码重复；对一些复杂的算法进行分割，将其算法中固定不变的部分设计为模板方法，而一些可以改变的细节由其子类来实现；通过模板方法模式还可以控制子类的扩展。
ü 桥接模式(BridgePattern)：将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。
ü Bridge Pattern: Decouple an abstraction from its implementation sothat the two can vary independently.
ü 桥接模式的主要优点是分离抽象接口及其实现部分，是比多继承方案更好的解决方法，桥接模式还提高了系统的可扩充性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统，实现细节对客户透明，可以对用户隐藏实现细节；其主要缺点是增加系统的理解与设计难度，且识别出系统中两个独立变化的维度并不是一件容易的事情。
ü 桥接模式适用情况包括：需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系；抽象化角色和实现化角色可以以继承的方式独立扩展而互不影响；一个类存在两个独立变化的维度，且这两个维度都需要进行扩展；设计要求需要独立管理抽象化角色和具体化角色；不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统。