软件体系结构与设计模式笔记样本.doc

第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 Case Modeling）是使用用例办法来描述系统功能需求过程，用例建模增进并勉励了顾客参加，这是保证项目成功核心因素之一。
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 顺序图定义
ü 顺序图(Sequence Diagram)是一种强调对象间消息传递顺序交互图，又称为时序图或序列图。
w 状态图定义
ü 状态图(Statechart Diagram)用来描述一种特定对象所有也许状态及其引起状态转移事件。

第2章_面向对象设计原则
w 单一职责原则规定在软件系统中，一种类只负责一种功能领域中相应职责。
w 开闭原则规定一种软件实体应当对扩展开放，对修改关闭，即在不修改源代码基本上扩展一种系统行为。
w 里氏代换原则可以通俗表述为在软件中如果可以使用基类对象，那么一定可以使用其子类对象。
w 依赖倒转原则规定抽象不应当依赖于细节，细节应当依赖于抽象；要针对接口编程，不要针对实现编程。
w 接口隔离原则规定客户端不应当依赖那些它不需要接口，即将某些大接口细化成某些小接口供客户端使用。
w 合成复用原则规定复用时尽量使用对象组合，而不使用继承。
w 迪米特法则规定一种软件实体应当尽量少与其她实体发生互相作用。
第3章_设计模式概述
w 设计模式定义
ü 设计模式(Design Pattern)是一套被重复使用、多数人知晓、通过度类编目、代码设计经验总结，使用设计模式是为了可重用代码、让代码更容易被她人理解、保证代码可靠性。
ü 设计模式普通有如下几种基本要素：模式名称、问题、目、解决方案、效果、实例代码和有关设计模式，其中核心元素涉及如下四个方面：
w 模式名称 (Pattern name)
w 问题 (Problem)
w 解决方案 (Solution)
w 效果 (Consequences)

范畴\目
创立型模式
构造型模式
行为型模式
类模式
工厂办法模式
（类）适配器模式
解释器模式
模板办法模式
对象模式
抽象工厂模式
建造者模式
原型模式
单例模式
（对象）适配器模式
桥接模式
组合模式
装饰模式
外观模式
享元模式
代理模式
职责链模式
命令模式
迭代器模式
中介者模式
备忘录模式
观测者模式
状态模式
方略模式
访问者模式

第4章_简朴工厂模式
ü 简朴工厂模式(Simple Factory 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()； //依照参数创立详细产品
}
else if(type.equalsIgnoreCase("creditcard"))
{
return new CreditcardPay()； //依照参数创立详细产品
}
……
}
}
ü 简朴工厂模式最大缺陷是当有新产品要加入到系统中时，必要修改工厂类，加入必要解决逻辑，这违背了“开闭原则”。
ü 简朴工厂模式最大长处在于实现对象创立和对象使用分离，将对象创立交给专门工厂类负责，但是其最大缺陷在于工厂类不够灵活，增长新详细产品需要修改工厂类判断逻辑代码，并且产品较多时，工厂办法代码将会非常复杂。
ü 简朴工厂模式合用状况涉及：工厂类负责创立对象比较少；客户端只懂得传入工厂类参数，对于如何创立对象不关怀。

第5章_工厂办法模式
ü 工厂办法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创立型模式。在工厂办法模式中，工厂父类负责定义创立产品对象公共接口，而工厂子类则负责生成详细产品对象，这样做目是将产品类实例化操作延迟到工厂子类中完毕，即通过工厂子类来拟定究竟应当实例化哪一种详细产品类。
ü 抽象工厂类代码：
public abstract class PayMethodFactory
{
public abstract AbstractPay getPayMethod();
}
ü 详细工厂类代码：
public class CashPayFactory extends PayMethodFactory
{
public AbstractPay getPayMethod()
{
return new CashPay();
}
}
ü 客户类代码片段：
PayMethodFactory factory;
AbstractPay payMethod；
factory=new CashPayFactory();
payMethod =factory.getPayMethod();
payMethod.pay()；

ü 工厂办法模式重要长处是增长新产品类时不必修改既有系统，并封装了产品对象创立细节，系统具备良好灵活性和可扩展性；其缺陷在于增长新产品同步需要增长新工厂，导致系统类个数成对增长，在一定限度上增长了系统复杂性。 符合开闭原则。
ü 工厂办法模式合用状况涉及：一种类不懂得它所需要对象类；一种类通过其子类来指定创立哪个对象；将创立对象任务委托给各种工厂子类中某一种，客户端在使用时可以不必关怀是哪一种工厂子类创立产品子类，需要时再动态指定。

第6章_抽象工厂模式
ü 抽象工厂模式(Abstract Factory Pattern)：提供一种创立一系列有关或互相依赖对象接口，而不必指定它们详细类。抽象工厂模式又称为Kit模式，属于对象创立型模式。
ü 详细工厂类典型代码如下：
public class ConcreteFactory1 extends AbstractFactory
{
public AbstractProductA createProductA()
{
return new ConcreteProductA1();
}
public AbstractProductB createProductB()
{
return new ConcreteProductB1();
}
}
ü 抽象工厂模式重要长处是隔离了详细类生成，使得客户并不需要懂得什么被创立，并且每次可以通过详细工厂类创立一种产品族中各种对象，增长或者替代产品族比较以便，增长新详细工厂和产品族很以便；重要缺陷在于增长新产品级别构造很复杂，需要修改抽象工厂和所有详细工厂类，对“开闭原则”支持呈现倾斜性。
ü 抽象工厂模式合用状况涉及：一种系统不应当依赖于产品类实例如何被创立、组合和表达细节；系统中有多于一种产品族，而每次只使用其中某一产品族；属于同一种产品族产品将在一起使用；系统提供一种产品类库，所有产品以同样接口浮现，从而使客户端不依赖于详细实现。

第9章_单例模式
ü 单例模式(Singleton Pattern)：单例模式保证某一种类只有一种实例，并且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问办法。
ü 单例模式要点有三个：一是某个类只能有一种实例；二是它必要自行创立这个实例；三是它必要自行向整个系统提供这个实例。单例模式是一种对象创立型模式。单例模式又名单件模式或单态模式。

ü 单例模式实当代码如下所示：
public class Singleton
{
private static Singleton instance=null； //静态私有成员变量
//私有构造函数
private Singleton()
{
}

//静态公有工厂办法，返回唯一实例
public static Singleton getInstance()
{
if(instance==null)
instance=new Singleton();
return instance;
}
}
ü 单例模式重要长处在于提供了对唯一实例受控访问并可以节约系统资源；其重要缺陷在于由于缺少抽象层而难以扩展，且单例类职责过重。
ü 单例模式合用状况涉及：系统只需要一种实例对象；客户调用类单个实例只容许使用一种公共访问点。
ü 饿汉式单例与懒汉式单例类比较
ü 饿汉式单例类在自己被加载时就将自己实例化。单从资源运用效率角度来讲，这个比懒汉式单例类稍差些。从速度和反映时间角度来讲，则比懒汉式单例类稍好些。
ü 懒汉式单例类在实例化时，必要解决好在各种线程同步初次引用此类时访问限制问题，特别是当单例类作为资源控制器，在实例化时必然涉及资源初始化，而资源初始化很有也许耗费大量时间，这意味着浮现多线程同步初次引用此类机率变得较大，需要通过同步化机制进行控制。

第10章_适配器模式
ü 适配器模式(Adapter Pattern) ：将一种接口转换成客户但愿另一种接口，适配器模式使接口不兼容那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类构造型模式，也可以作为对象构造型模式。
ü 典型类适配器代码：
public class Adapter extends Adaptee implements Target
{
public void request()
{
specificRequest();
}
}
ü 典型对象适配器代码：
public class Adapter extends Target
{
private Adaptee adaptee;

public Adapter(Adaptee adaptee)
{
this.adaptee=adaptee;
}

public void request()
{
adaptee.specificRequest();
}
}
类适配器

对象适配器

ü 适配器模式重要长处是将目的类和适配者类解耦，增长了类透明性和复用性，同步系统灵活性和扩展性都非常好，更换适配器或者增长新适配器都非常以便，符合“开闭原则”；类适配器模式缺陷是适配器类在诸多编程语言中不能同步适配各种适配者类，对象适配器模式缺陷是很难置换适配者类办法。
ü 适配器模式合用状况涉及：系统需要使用既有类，而这些类接口不符合系统需要；想要建立一种可以重复使用类，用于与某些彼此之间没有太大关联某些类一起工作。

第14章_外观模式
ü 外观模式(Facade Pattern)：外部与一种子系统通信必要通过一种统一外观对象进行，为子系统中一组接口提供一种一致界面，外观模式定义了一种高层接口，这个接口使得这一子系统更加容易使用。外观模式又称为门面模式，它是一种对象构造型模式。
外观模式也是“迪米特法则”

ü 典型外观角色代码：
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章_代理模式
ü 代理模式(Proxy Pattern) ：给某一种对象提供一种代理，并由代理对象控制对原对象引用。代理模式英文叫做Proxy或Surrogate，它是一种对象构造型模式。

ü 典型代理类实当代码：
public class Proxy implements Subject
{
private RealSubject realSubject = new RealSubject()；
public void preRequest()
{…...}
public void request()
{
preRequest();
realSubject.request();
postRequest();
}
public void postRequest()
{……}
}

ü 代理模式长处在于可以协调调用者和被调用者，在一定限度上减少了系统耦合度；其缺陷在于由于在客户端和真实主题之间增长了代理对象，因而有些类型代理模式也许会导致祈求解决速度变慢，并且实当代理模式需要额外工作，有些代理模式实现非常复杂。
ü 模式合用环境
ü 依照代理模式使用目，代理模式有如下几种类型（续）：
ü 保护(Protect or Access)代理：控制对一种对象访问，可以给不同顾客提供不同级别使用权限。
ü 缓冲(Cache)代理：为某一种目的操作成果提供暂时存储空间，以便各种客户端可以共享这些成果。
ü 防火墙(Firewall)代理：保护目的不让恶意顾客接近。
ü 同步化(Synchronization)代理：使几种顾客可以同步使用一种对象而没有冲突。
ü 智能引用(Smart Reference)代理：当一种对象被引用时，提供某些额外操作，如将此对象被调用次数记录下来等。

第23章_观测者模式
ü 观测者模式(Observer Pattern)：定义对象间一种一对多依赖关系，使得每当一种对象状态发生变化时，其有关依赖对象皆得到告知并被自动更新。观测者模式又叫做发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。观测者模式是一种对象行为型模式。

ü 典型抽象目的类代码如下所示：
import java.util.*;
public abstract class Subject
{
protected ArrayList observers = new ArrayList();
public abstract void attach(Observer observer);
public abstract void detach(Observer observer);
public abstract void notify();
}
ü 典型详细目的类代码如下所示：
public class ConcreteSubject extends Subject
{
public void attach(Observer observer)
{
observers.add(observer);
}

public void detach(Observer observer)
{
observers.remove(observer);
}

public void notify()
{
for(Object obs:observers)
{
((Observer)obs).update();
}
}
}
ü 典型抽象观测者代码如下所示：
public interface Observer
{
public void update();
}
ü 典型详细观测者代码如下所示：
public class ConcreteObserver implements Observer
{
public void update()
{
//详细更新代码
}
}
ü 客户端代码片段如下所示：
Subject subject = new ConcreteSubject();
Observer observer = new ConcreteObserver();
subject.attach(observer);
subject.notify();

w 观测者模式重要长处在于可以实现表达层和数据逻辑层分离，并在观测目的和观测者之间建立一种抽象耦合，支持广播通信；其重要缺陷在于如果一种观测目的对象有诸多直接和间接观测者话，将所有观测者都告知到会耗费诸多时间，并且如果在观测者和观测目的之间有循环依赖话，观测目的会触发它们之间进行循环调用，也许导致系统崩溃。
w 观测者模式合用状况涉及：一种抽象模型有两个方面，其中一种方面依赖于另一种方面；一种对象变化将导致其她一种或各种对象也发生变化，而不懂得详细有多少对象将发生变化；一种对象必要告知其她对象，而并不懂得这些对象是谁；需要在系统中创立一种触发链。

ü 组合模式(Composite Pattern)：组合各种对象形成树形构造以表达“整体-某些”构造层次。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）使用品有一致性。
ü Composite Pattern：Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
ü 组合模式重要长处在于可以以便地对层次构造进行控制，客户端调用简朴，客户端可以一致使用组合构造或其中单个对象，顾客就不必关怀自己解决是单个对象还是整个组合构造，简化了客户端代码；其缺陷在于使设计变得更加抽象，且增长新构件时也许会产生某些问题，并且很难对容器中构件类型进行限制。
ü 组合模式合用状况涉及：需要表达一种对象整体或某些层次；让客户可以忽视不同对象层次变化，客户端可以针对抽象构件编程，不必关怀对象层次构造细节；对象构造是动态并且复杂限度不同样，但客户需要一致地解决它们。

ü 命令模式(Command Pattern)：将一种祈求封装为一种对象，从而使咱们可用不同祈求对客户进行参数化；对祈求排队或者记录祈求日记，以及支持可撤销操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。
ü Command Pattern：Encapsulate a request as an object，thereby letting you parameterize clients with different requests，queue or log requests，and support undoable operations.
ü 命令模式重要长处在于减少系统耦合度，增长新命令很以便，并且可以比较容易地设计一种命令队列和宏命令，并以便地实现对祈求撤销和恢复；其重要缺陷在于也许会导致某些系统有过多详细命令类。
ü 命令模式合用状况涉及：需要将祈求调用者和祈求接受者解耦，使得调用者和接受者不直接交互；需要在不同步间指定祈求、将祈求排队和执行祈求；需要支持命令撤销操作和恢复操作；需要将一组操作组合在一起，即支持宏命令。

ü 迭代器模式(Iterator Pattern) ：提供一种办法来访问聚合对象，而不用暴露这个对象内部表达，其别名为游标(Cursor)。迭代器模式是一种对象行为型模式。
ü Iterator Pattern：Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
ü 迭代器模式重要长处在于它支持以不同方式遍历一种聚合对象，还简化了聚合类，并且在同一种聚合上可以有各种遍历；其缺陷在于增长新聚合类需要相应增长新迭代器类，类个数成对增长，这在一定限度上增长了系统复杂性。
ü 迭代器模式合用状况涉及：访问一种聚合对象内容而不必暴露它内部表达；需要为聚合对象提供各种遍历方式；为遍历不同聚合构造提供一种统一接口。

ü 模板办法模式(Template Method Pattern)：定义一种操作中算法骨架，而将某些环节延迟到子类中，模板办法使得子类可以不变化一种算法构造即可重定义该算法某些特定环节。模板办法是一种类行为型模式。
ü Template Method Pattern：Define the skeleton of an algorithm in an operation，deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.
ü 模板办法模式长处在于在子类定义详细解决算法时不会变化算法构造，实现了代码复用，通过对子类扩展可以增长新行为，符合“开闭原则”；其缺陷在于需要为每个不同实现都定义一种子类，这会导致类个数增长，系统更加庞大，设计也更加抽象
ü 模板办法模式合用状况涉及：一次性实现一种算法不变某些，并将可变行为留给子类来实现；各子类中公共行为应被提取出来并集中到一种公共父类中以避免代码重复；对某些复杂算法进行分割，将其算法中固定不变某些设计为模板办法，而某些可以变化细节由其子类来实现；通过模板办法模式还可以控制子类扩展。
ü 桥接模式(Bridge Pattern)：将抽象某些与它实现某些分离，使它们都可以独立地变化。它是一种对象构造型模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。
ü Bridge Pattern：Decouple an abstraction from its implementation so that the two can vary independently.
ü 桥接模式重要长处是分离抽象接口及其实现某些，是比多继承方案更好解决办法，桥接模式还提高了系统可扩充性，在两个变化维度中任意扩展一种维度，都不需要修改原有系统，实现细节对客户透明，可以对顾客隐藏实现细节；其重要缺陷是增长系统理解与设计难度，且辨认出系统中两个独立变化维度并不是一件容易事情。
ü 桥接模式合用状况涉及：需要在构件抽象化角色和详细化角色之间增长更多灵活性，避免在两个层次之间建立静态继承联系；抽象化角色和实现化角色可以以继承方式独立扩展而互不影响；一种类存在两个独立变化维度，且这两个维度都需要进行扩展；设计规定需要独立管理抽象化角色和详细化角色；不但愿使用继承或由于多层次继承导致系统类个数急剧增长系统。