【读书笔记】设计模式第6章：行为型模式2
时间：2014-05-12 23:20:22
收藏：0
阅读：436
本文主要分析了中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式，介绍它们的定义、优缺点、使用场景，以及实例代码。为了深刻地理解设计模式，最重要的还是动手编写代码。
我参照书中的例程重新构想了一些更加生动、易于理解的例子，希望大家喜欢。
代码可以通过以下链接进行浏览：
这些代码都经过编译运行，保证没有错误。
- 中介者模式
- 定义
- 也叫调停者模式
- 用一个中介对象来封装一系列同事对象之间的交流，使得同事对象之间不需要显式地相互作用
- 角色：抽象中介者、具体中介者、抽象同事、具体同事
- 优点
- 减少类之间的依赖
- 避免同事对象之间的过度耦合
- 将对象的行为和协作抽象化
- 注意事项
- 不应当在责任划分混乱的时候使用
- 不应该在数据类和操作类之间使用
- 正确理解封装
- 定义
- 观察者模式
- 定义
- 也叫发布订阅模式
- 定义对象之间一种一对多的依赖关系，使得每当这个类被修改时，所有依赖于这个类的对象都会收到通知并得到更新
- 角色：抽象主题、具体主题、抽象观察者、具体观察者
- 优点
- 观察者和被观察者之间是抽象耦合的
- 支持广播通信
- 缺点
- 如果观察者非常多，则性能会变差
- 如果有循环依赖关系，则会导致死循环
- 如果是观察者异步执行的，需要保证观察者收到通知的顺序
- 观察者无法知道对象是如何变化的
- 使用场景
- 关联行为场景
- 事件多级触发场景
- 跨系统的消息交换场景
- 注意事项
- 避免广播链。一个观察者也可以同时为被观察者。这种情况维护性很差
- 异步处理问题。异步处理要考虑线程安全
- 定义
- 备忘录模式
- 定义
- 又称快照模式，Token模式
- 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存状态。这样，以后就可以恢复原先保存的状态了
- 角色：发起人、备忘录、负责人（负责管理备忘录）
- 使用场景
- 需要保存和恢复数据的相关状态场景
- 提供一个可回滚的操作
- 需要监控副本的场景。用于记录日志，用作后续对程序分析
- 数据库中的事务
- 注意事项
- 生命周期。建立备忘录之后就要使用，不使用就马上删除
- 性能。不要频繁使用备忘录
- 定义
- 访问者模式
- 定义
- 封装一些作用于某种数据结构中各元素的操作，它可以在不改变数据结构的前提下，定义一种新的操作
- 角色：抽象访问者、具体访问者、抽象元素、具体元素、结构对象
- 优点
- 容易增加新的操作
- 将有关的行为集中到一个访问者的对象中，而不是分散到一个个元素中
- 可以同时访问多个类中的私有成员
- 累积状态。每个访问者都集中了相关的行为，所以在访问的过程中将执行操作的状态积累在自己内部，而不是分散到很多的元素中
- 缺点
- 不容易增加新的元素类型
- 破坏封装性。访问者必须知道类中的实现细节
- 违背了依赖倒置原则。访问者依赖于具体的元素，而不是抽象的元素
- 使用场景
- 一个对象包含很多类对象，由于它们有不同的接口，无法使用迭代器迭代每个对象。
- 需要对一个对象结构体中的对象进行很多不相关的操作
- 业务规则要求遍历多个不同类型的对象
- 定义
- 状态模式
- 定义
- 又称为状态对象模式
- 当一个对象改变状态时，允许改变其行为，这个对象好像看起来改变了类型一样
- 角色：抽象状态、具体状态、环境
- 优点
- 结构清晰
- 遵循设计原则
- 封装性良好
- 缺点
- 子类太多，不易维护
- 使用场景
- 行为随着状态的改变而改变的情形
- 代码中存在很长的case语句
- 定义
- 解释器模式
- 定义
- 给定一门语言，定义它的文法表示，并定义一个解释器，该解释器使用该表达式来解释语言中的句子
- 角色：抽象表达式、终结符表达式、非终结符表达式、环境、客户端
- 优点
- 简单的语法分析工具
- 语法可扩展
- 缺点
- 类的数量过多
- 采用递归调用
- 使用场景
- 解决重复发生的问题
- 一个简单语法需要解释的场景
- 正则表达
- 定义
评论（0）