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