第10讲：软件设计模式.ppt

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