设计模式PPT-工大.ppt

状态模式的参与者 Context 客户感兴趣的接口；维护一个ConcreteState子类实例，该实例定义了当前状态 State 封装与Context的一个特定状态相关的行为接口 ConcreteState subclasses 实现一个与Context的一个状态相关的行为 状态模式的效果分析 使用State模式，动作完成后，可以自动切换到下一个状态，客户无须知道具体的切换逻辑。每一个ConcreteState实例只需知道本状态后可能过渡到哪些状态及相应条件即可 实现了与状态相关的行为的局部化 使用状态模式将状态的切换逻辑放到State的派生类中，动作的实现供派生类进行调用，实现了逻辑和动作的解耦 访问者模式的由来 如何扩展一个现有的类层次结构来实现新行为？一般的方法是给类添加新的方法。但是万一新行为和现有对象模型不兼容怎么办？ 类层次结构设计人员可能无法预知以后开发过程中将会需要哪些功能 如果已有的类层次结构不允许修改代码，怎么能扩展行为呢？ 访问者模式的意图和适用性 意图 作用于某个对象群中各个对象的操作。可在不改变这些对象本身的情况下，定义作用于这些对象的新操作 适用场合 一个对象结构包含很多类对象，它们有不同的接口，想对这些对象实施一些依赖于其具体类的操作 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类 当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作 定义对象结构的类很少改变，但经常需要在此结构上定义新的操作 访问者模式的结构 访问者模式的参与者 Visitor 为对象结构中的具体元素提供一个访问操作接口。该操作接口的名字和参数标识了要访问的具体元素角色。访问者可以通过该元素角色的特定接口直接访问它 ConcreteVisitor 实现Visitor接口的操作 Element 该接口定义一个accept操作接受具体的访问者 ConcreteElement 实现Element的accept操作 ObjectStructure 能枚举元素；可提供一个高层接口以允许访问者访问其元素；可以是一个复合（组合模式）或是一个集合 访问者模式的效果分析 优点 不修改具体元素类，就可以增加新操作。主要是通过元素类的accept方法接受一个visitor对象来实现的 缺点 不易频繁增加元素类，每增加一个元素类，就要在Visitor接口中写一个针对该元素的方法，还要修改Visitor子类 中介者模式的由来 传统图形界面存在若干复杂性问题 对象间紧密耦合，对象的修改必然导致相关对象也要修改 子类太多，每个不同的按钮都要生成一个不同子类，代码的复用性很差 交互关系分散在各个子类中，代码维护困难 应对需求变化的能力差，设想一下，如果新增一个组件，需要添加和修改的代码将涉及系统的多个类 如果把这些多对多的交互关系抽象出来集中到一个对象中来处理，所有的复杂性也就被集中到单一的对象中 中介者模式的意图和适用性 意图 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互 适用场合 在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系。遇到需求更改，直接引用关系将面临不断的变化，可使用一个“中介对象”来管理对象之间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化 中介者模式的结构 中介者模式的参与者 Mediator 定义一个接口用于与各同事（Colleague）对象通信 ConcreteMediator 通过协调各同事对象实现协作行为 维护每个需要协调的同事的引用 Colleague Class 维护一个中介者对象的引用 每个同事对象在需要与其他的同事通信时，与中介者通信 中介者模式效果分析 减少了子类生成 中介者将原本分布于多对象间的行为集中到一起，使同一基类派生出的不同子类间的差异被分离出来，使子类化作用失效，减少了子类的派生也就增加了系统的可复用性 如：两个Button类派生的按钮子类唯一不同是Clicked方法，当中介者类将这两个按钮子类的Clicked方法都集中到自己的方法中后，这两个按钮子类就完全相同，无需派生子类 松耦合 中介者模式将各对象解耦，各对象之间松耦合，可以独立改变和复用各Colleague类 中介者模式的效果分析 简化了对象间关联 用Mediator和Colleague间一对多交互来代替各Colleague间多对多交互，一对多的关系更易于理解、维护和扩展 封装变化 中介者在封装交互的同时也将变化封装起来，交互关系的变化只影响Mediator类的代码，各Colleague类的代码无需修