15观察者与状态模式-526互联

观察者模式

定义：观察者模式(Observer Pattern)：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象都得到通知并被自动更新。
1. 对象行为型模式
2. 别名：
  - 发布-订阅(Publish/Subscribe)模式
  - 模型-视图(Model/View)模式
  - 源-监听器(Source/Listener)模式
  - 从属者(Dependents)模式
简单结构：4个角色
1. Subject（目标）
2. ConcreteSubject（具体目标）
3. Observer（观察者）
4. ConcreteObserver（具体观察者）
UML：
优缺点：
1. 优点：
  - 可以实现表示层和数据逻辑层的分离
  - 在观察目标和观察者之间建立一个抽象的耦合
  - 支持广播通信，简化了一对多系统设计的难度
  - 符合开闭原则
2. 缺点：
  - 将所有的观察者都通知到会花费很多时间
  - 如果存在循环依赖时可能导致系统崩溃
  - 没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而只是知道观察目标发生了变化
适用环境：
1. 一个抽象模型有两个方面，其中一个方面依赖于另一个方面
2. 一个对象的改变将导致一个或多个其他对象发生改变，且并不知道具体有多少对象将发生改变，也不知道这些对象是谁
3. 需要在系统中创建一个触发链

状态模式

定义：状态模式(State Pattern)：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
1. 对象行为型模式，又名状态对象(Objects for States)
2. 用于解决系统中复杂对象的状态转换以及不同状态下行为的封装问题
3. 将一个对象的状态从该对象中分离出来
4. 对于客户端而言，无须关心对象状态的转换以及对象所处的当前状态
简单结构：3个角色
1. Context（环境类）
2. State（抽象状态类）
3. ConcreteState（具体状态类）
UML：
优缺点：
1. 优点：
  - 封装了状态的转换规则
  - 将所有与某个状态有关的行为放到一个类中，只需要注入一个不同的状态对象即可使环境对象拥有不同的行为
  - 允许状态转换逻辑与状态对象合成一体，而不是提供一个巨大的条件语句块
  - 可以让多个环境对象共享一个状态对象
2. 缺点：
  - 会增加系统中类和对象的个数，导致系统运行开销增大
  - 结构与实现都较为复杂，如果使用不当将导致程序结构和代码混乱，增加系统设计的难度
  - 对开闭原则的支持并不太好，增加新的状态类需要修改负责状态转换的源代码，否则无法转换到新增状态；而且修改某个状态类的行为也需要修改对应类的源代码
适用环境
1. 对象的行为依赖于它的状态（例如某些属性值），状态的改变将导致行为的变化
2. 在代码中包含大量与对象状态有关的条件语句，这些条件语句的出现会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，并且导致客户类与类库之间的耦合增强