2015年软考系统架构设计师学习笔记第七章（2）
发布时间：2010/12/4 22:26:04 来源：城市学习网 编辑：ziteng
7.2 设计模式实例
7.2.1 创建性模式
通过该了的子类来创建对象的。但是，这可能会 限制在系统内创建对象的类型或数目。
1、Abstract Factory 模式
在不指定具体类的情况下，为创建一些列 相关 或 相互依赖的对象提供了接口。
提供了一个可以 确定合适的具体类 的抽象类。
优点：
可以与具体类分开。
更容易在产品系列中转换。
提高了产品间的一致性。
以下情况应该使用 Abstract Factory 模式：
系统独立于产品的 创建、组成、表示。
系统配置成 具有多个产品的 系列。
相关产品对象系列 是共同使用的，而且必须确保这一点。
你希望提供产品的类库，只开放其接口。
2、Builder 模式
将复杂对象的 构件与表示 相分离，相同的构造过程可以创建不同的对象，通过只指定对象的 类型和内容。
一次就可以创建所有的复杂对象，而其他模式一次就只能创建一个对象。
优点：
可以对产品内部表示进行改变。
将构造代码与表示代码相分离。
以下情况应该使用 Builder 模式：
算法独立于 组成对象。
构造过程必须允许已构件对象有不同表示。
3、Factory Method 模式
实例化工作交给其子类，可以在不修改代码的情况下引入新类，因为新类只实现了接口。
优点：
代码只处理接口，因此可以使用任何实现了接口的类。
在类中创建对象比直接在客户端创建要更加灵活。
以下情况中，应该使用 Factory Method 模式：
类不能预料它必须创建的对象的类。
类希望其子类指定要创建的对象。
类将责任转给某个帮助子类，而用户希望定位那个被授权的帮助子类。
4、Prototype 模式
只要将对象类定义成能够复制自身就可以实现。
优点如下：
可以在运行时 添加或删除产品。
通过改变值 指定新对象。
通过改变结构 制定新对象。
减少子类的生成和使用。
可以用类 动态地配置 应用程序。
以下情况中，应该使用Prototype 模式：
运行时，指定需要实例化的类，例如动态载入。
避免构建与产品的类层次结构相似的 工厂类层次结构。
5、Singleton 模式
确保 一个类只有一个实例，并且提供全局访问入口，确保使用这个 实例 所有的对象 使用相同的实例。
优点：
对单个实例的受控访问。
命名空间的减少。
允许改进操作和表示。
允许改变数目的实例。
比类操作更灵活。 [NextPage] 7.2.2 结构性模式
机构性模式 控制 较大部分之间的 关系。
它将以不同的方式 影响应用程序。
允许在补充写代码或自定义代码的情况下 创建系统。
具有增强的 重复使用性和应用性能。
1、Adapter 模式
可以充当两个类之间的媒介，可以转换一个类的接口，被另外一个类使用，使得具有不兼容接口的类能够系统使用。
优点：
允许多个不兼容的对象 进行交互和通信。
提高已有功能的重复使用性。
以下情况，应该使用 Adapter 模式：
要使用已有类，而该类接口与所需的接口并不匹配。
要创建可重用的类，该类可以与 不相关 或 未知类 进行协作。
要在一个 不同于已知对象接口的接口环境中 使用对象。
必须要进行多个源之间的接口转换的时候。
2、Bridge模式
将一个复杂的组件 分成两个独立的 但又相关的 继承层次结构：功能性抽象和内部实现。
优点：
接口与实现相分离。
提高了可扩展性。
对客户端隐藏了实现的细节。
以下情况中，应该使用 Bridge 模式：
避免在抽象及其实现之间 存在永久的绑定。
抽象及其实现 可以使用子类进行扩展。
抽象的实现被改动 不用重新编译代码。
3、Composite 模式
创建树形层次结构来改变复杂性。
优点：
定义了由 主要对象 和 符合对象 组成的类层次结构。
添加新的组件类型更加简单。
结构的灵活性和可管理性的接口。
以下情况中，应该使用 Composite 模式：
想要表示对象的整个 或者部分的层次结构。
想要客户端能够忽略符合对象和单个对象之间的差异。
结构可以具有任何级别的复杂性，而且是动态的。
4、Decorator 模式
不修改对象外观和功能的情况下 添加或删除对象功能。
优点：
比静态继承具有更大的灵活性。
避免了特征装载的类 处于层次结构的 过高级别。
简化了编码。
改进了对象的扩展性。
在以下情况中，应该使用 Decorator 模式：
在单个对象中 动态并且透明地 添加责任，不会影响其他对象。
以后可能要修改的对象中添加责任。
无法通过静态子类化实现扩展时。
5、Facade 模式
为子系统中的一组接口 提供了一个统一的接口。更容易使用子系统的高级接口。
优点：
在不减少系统所提供的选项的情况下，为复杂系统提供了简单接口。
屏蔽了子系统组件。
提高若耦合度。
将客户端请求转换后 发送给能够处理这些请求的 子系统。
以下情况中，应使用 Facade 模式：
为复杂的子系统提供简单的接口。
客户端和抽象的实现类中 存在许多依赖关系。
想要对子系统进行分层。
6、Flyweight 模式
通过共享对象 减少对象数目。
通过共享一个接口来避免使用多个具有相同信息的实例 所带来的开销。
优点：
减少了要处理的对象数目。
如果对象能够持续，可以减少内存和存储设备。
以下情况中，应该使用 Flyweight 模式：
应用程序使用大量的对象。
由于对象数目巨大，导致很高的存储开销。
不依赖于对象的身份。
