软件设计与体系结构齐治昌资料.ppt

(6) Iterator 核心思想归纳：通过将与遍历有关的部分从聚合对象的描述中分离出来、单独成类，能够将遍历的状态信息用一个独立对象记录，从而可有效处理多种遍历和并发遍历。另外，本模式可与Factory Method模式配合使用，支持从聚合对象直接创建相应的聚合器。 (7) Observer 动机与实例：Word软件的“窗口拆分”功能。 (7) Observer 动机与实例：Word软件的“窗口拆分”功能。 (7) Observer 动机与实例：Word软件的“窗口拆分”功能。 (7) Observer 动机与实例：Word软件的“窗口拆分”功能。 (7) Observer 适用场合：如果对象之间存在一对多的数据依赖关系、且当被依赖对象的数据改变时所有依赖于它的对象都应得到通知并自动更新，那么可使用本模式。被依赖的对象称为发布者，负责发布数据并通知所有的订阅者（即依赖于该发布者的对象），以便订阅者与发布者的状态保持一致。 前面的例子中，Document对象为发布者，而Window对象为订阅者。因此，本模式也称为发布-订阅（Publish-Subscribe）模式。订阅者也可称为观察者（Observer），它似乎在时刻观察发布者的状态，并及时更新自己。 (7) Observer 结构： (7) Observer 核心思想归纳：对象是对数据和函数的封装，当一个类包含了太多的函数（或称操作）时，我们倾向于将其拆分为多个相互协作的类，每个协作类描述一部分行为、包含原来的一部分数据和函数，但这种拆分有一个副作用：因为各协作对象很可能会共享部分数据，所以需要维护相关对象在数据上的一致性。通过使用Observer模式，能够为相关对象制定一个交互协议，专门用作数据的一致性维护。 (1) Factory Method 核心思想归纳：在父类中，将创建对象的操作包装为一个虚函数，在描述公共行为的过程中调用该函数；在子类中重定义该虚函数来定制创建的对象，从而间接定制公共行为。利用虚函数的多态机制，Factory Method模式使得父类可集中描述公共行为，而将特别行为（不同对象的创建）抽放于子类。 (2) Abstract Factory 动机与实例：魔力管道。 在前面的设计中，三个MakeBallFactoryMethod工厂方法散放在三个MagicPipe类中。为了降低复杂性，可以把所有的创建动作拆分出来单独考虑。 即：创建球的动作单独形成一个工厂类，专门创建对象。 (2) Abstract Factory 动机与实例：设计3 (2) Abstract Factory 动机与实例：设计4 不仅有球、还有盒子等小实体，抽象工厂类专门创建各种小实体 (2) Abstract Factory 动机与实例：设计5 混合管道和小实体 (2) Abstract Factory 适用场合：当需要创建一组多种风格的小实体、且具体创建方式又要灵活可调整时，可使用Abstract Factory模式，将公共的创建行为描述为一个抽象类，而将具体的创建方式用该抽象类的子类来描述。 (2) Abstract Factory 结构： (2) Abstract Factory 核心思想归纳：为了提供灵活性，将需要创建的同一风格的一组小实体的一般特征提取出来，用一组抽象产品类来描述，同时将创建行为封装为一个抽象工厂类，提供通用的创建接口，而将各种具体的产品和具体的创建行为用抽象产品类和抽象工厂类的子类来描述。从而使得BigEntity和具体的产品特性和具体的创建行为隔离开来，既降低了耦合度，也使得灵活调整创建行为成为可能。 (3) Singleton 动机与实例：日志功能，在一个应用程序内部一般只需要一个日志实例即可。 实现方案1 公有的构造函数 (3) Singleton 实现方案1 全局变量 (3) Singleton 实现方案1 需要日志的地方直接使用变量 g_log和相关接口函数 (3) Singleton 实现方案1：两个缺陷 一般情况下（如果只有一个日志文件）只需要一个Log实例即可，但上述做法不能保证Log的实例只有一个，当多个实例设置相同的日志文件的时候，还可能引起冲突； 这种做法使得g_log无论用到与否都要被创建。 (3) Singleton 实现方案2：使用Singleton模式 私有静态成员变量， 代替全局变量，指向log唯一实例 构造函数变为protected 不可能在类外部创建实例 静态私有函数代替全局变量， 获取实例指针 (3) Singleton 实现方案2：使用Singleton模式 #include “log.h” Log *log::theOnlyInstance=0; Log *Log::getInstance() {