16 State状态模式（行为型）

16 State（行为型）

- 状态图是计算机科学和相关领域中用来描述系统行为的一种图。
- 动机：

状态模式允许一个对象在其内部状态改变的时

候改变其行为。这个对象看上去就像改变了

它的类一样

- 什么时候用：

一个对象的行为取决于它的状态，并且它必须在运行时根据那个状态改变它的行为。

操作有很大的、由多个部分组成的条件语句，这些语句依赖于对象的状态。

- 结构：
  - （女朋友）Context:定义客户感兴趣的接口;维护定义当前状态的具体状态的实例。
  - 状态:定义一个接口，用于封装与上下文的特定状态关联的行为
  - 具体化状态:每个实现与上下文状态相关联的行为。
- 合作：
  - 上下文将特定于状态的请求委托给当前请求ConcreteState对象。
  - 上下文可以将自己作为参数传递给处理请求的状态对象。这允许状态对象在必要时访问上下文。
  - 上下文是客户端的主要接口。状态对象可以配置为上下文。一旦配置了上下文，它的客户端就不必直接处理状态对象。
  - 上下文或具体状态都可以决定在什么情况下哪个状态接替另一个状态

- 后果：
  - 它本地化特定于状态的行为，并为不同的状态划分行为。
  - 它使状态转换显式。
    - 当对象通过内部数据值定义其当前状态时，其状态转换没有显式表示;它们只作为一些变量的赋值出现。
  - 状态对象可以被共享(Flyweight)。
- 实现：
  - 状态模式没有指定哪个参与者定义状态转换的标准。
  - 如果这些标准是固定的，那么它们可以完全在上下文中实现。
  - 一般来说，更灵活和合适的是State子类本身指定它们的继承状态以及何时进行转换。
    - 通过定义新的状态子类，很容易修改或扩展逻辑。
    - 缺点是State子类至少知道另一个子类，这就引入了子类之间的实现依赖关系。
  - 惰性lazy:只在需要状态对象时创建它们，然后销毁它们。
    - 当运行时不知道将要输入的状态，并且上下文很少更改状态时。
  - 渴望eager:提前创造它们，永远不要摧毁它们。
    - 当状态发生快速变化时。
  - 例：
- 扩展：
  - 表驱动方法
    - 使用表将输入映射到状态转换。
    - 对于每个状态，表将每个可能的输入映射到后续状态。
      - 这种方法将条件代码转换为表查询。
    - 表的主要优点是它们的规律性:您可以通过修改数据而不是更改程序代码来更改转换标准。
    - 缺点：
      - 表查找通常不如函数调用有效。
      - 不太清楚，也很难理解。
      - 通常很难在状态转换的同时添加动作。
    - 表驱动方法和状态模式的关键区别
      - 状态模式建模特定于状态的行为。
      - 表驱动的方法侧重于定义状态转换。

- 策略模式是封装行为，一个状态，多个算法
- 而state有多个状态

16 State状态模式（行为型）

猜你喜欢