设计模式学习笔记--状态模式模式(详细笔记)

1. 概述

使用背景：

《大话设计模式》

“状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。当然，如果这个状态判断很简单,那就没必要用‘状态模式’了。”

菜鸟教程

• 对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
• 代码中包含大量与对象状态有关的条件语句。

定义：

《大话设计模式》

状态模式（State)，当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类。

**类型：**行为型

结构：

《大话设计模式》

《深入设计模式》

适用场景：

菜鸟教程

• 行为随状态改变而改变的场景。
• 条件、分支语句的代替者。
• 在行为受状态约束的时候使用状态模式，而且状态不超过 5 个。

《深入设计模式》

• 如果对象需要根据自身当前状态进行不同行为， 同时状态的数量非常多且与状态相关的代码会频繁变更的话， 可使用状态模式。

模式建议你将所有特定于状态的代码抽取到一组独立的类中。 这样一来， 你可以在独立于其他状态的情况下添加新状态或修改已有状态， 从而减少维护成本。

• 如果某个类需要根据成员变量的当前值改变自身行为， 从而需要使用大量的条件语句时， 可使用该模式。

状态模式会将这些条件语句的分支抽取到相应状态类的方法中。 同时， 你还可以清除主要类中与特定状态相关的临时成员变量和帮手方法代码。

• 当相似状态和基于条件的状态机转换中存在许多重复代码时， 可使用状态模式。

状态模式让你能够生成状态类层次结构， 通过将公用代码抽取到抽象基类中来减少重复。

《图说设计模式》

• 对象的行为依赖于它的状态（属性）并且可以根据它的状态改变而改变它的相关行为。
• 代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为，而且这些条件对应于对象的各种状态。

实现方式：

1. 确定哪些类是上下文。 它可能是包含依赖于状态的代码的已有类； 如果特定于状态的代码分散在多个类中， 那么它可能是一个新的类。

2. 声明状态接口。 虽然你可能会需要完全复制上下文中声明的所有方法， 但最好是仅把关注点放在那些可能包含特定于状态的行为的方法上。

3. 为每个实际状态创建一个继承于状态接口的类。 然后检查上下文中的方法并将与特定状态相关的所有代码抽取到新建的类中。

   在将代码移动到状态类的过程中， 你可能会发现它依赖于上下文中的一些私有成员。 你可以采用以下几种变通方式：

   • 将这些成员变量或方法设为公有。
   • 将需要抽取的上下文行为更改为上下文中的公有方法， 然后在状态类中调用。 这种方式简陋却便捷， 你可以稍后再对其进行修补。
   • 将状态类嵌套在上下文类中。 这种方式需要你所使用的编程语言支持嵌套类。

4. 在上下文类中添加一个状态接口类型的引用成员变量， 以及一个用于修改该成员变量值的公有设置器。

5. 再次检查上下文中的方法， 将空的条件语句替换为相应的状态对象方法。

6. 为切换上下文状态， 你需要创建某个状态类实例并将其传递给上下文。 你可以在上下文、各种状态或客户端中完成这项工作。 无论在何处完成这项工作， 该类都将依赖于其所实例化的具体类。

优点：

《大话设计模式》

• “状态模式的好处是将与特定状态相关的行为局部化，并且将不同状态的行为分割开来”

菜鸟教程/《图说设计模式》

1、封装了转换规则。

2、枚举可能的状态，在枚举状态之前需要确定状态种类。

3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。

4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。

5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。

《深入设计模式》

• 单一职责原则。 将与特定状态相关的代码放在单独的类中。
• 开闭原则。 无需修改已有状态类和上下文就能引入新状态。
• 通过消除臃肿的状态机条件语句简化上下文代码。

缺点：

菜鸟教程/《图说设计模式》

• 1、状态模式的使用必然会增加系统类和对象的个数。
• 2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
• 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。

《深入设计模式》

如果状态机只有很少的几个状态， 或者很少发生改变， 那么应用该模式可能会显得小题大作。

与其他设计模式的联系：

《深入设计模式》

• 桥接模式、 状态模式和策略模式 （在某种程度上包括适配器模式） 模式的接口非常相似。 实际上， 它们都基于组合模式——即将工作委派给其他对象， 不过也各自解决了不同的问题。 模式并不只是以特定方式组织代码的配方， 你还可以使用它们来和其他开发者讨论模式所解决的问题。
• 状态可被视为策略的扩展。 两者都基于组合机制： 它们都通过将部分工作委派给 “帮手” 对象来改变其在不同情景下的行为。 策略使得这些对象相互之间完全独立， 它们不知道其他对象的存在。 但状态模式没有限制具体状态之间的依赖， 且允许它们自行改变在不同情景下的状态。

《图解设计模式》

• Singleton模式

  ingleton模式常常会出现在ConcreteState角色中。在示例程序中，我们就使用了Singleton模式。这是因为在表示状态的类中并没有定义任何实例字段(即表示实例的状态的字段)。

• Flyweight模式
  在表示状态的类中并没有定义任何实例字段。因此，有时我们可以使用Flyweight模式在多个Context角色之间共享ConcreteState角色。

识别方法： 状态模式可通过受外部控制且能根据对象状态改变行为的方法来识别。

2. 使用实例

菜鸟教程

• 1、打篮球的时候运动员可以有正常状态、不正常状态和超常状态。

• 2、曾侯乙编钟中，‘钟是抽象接口’,'钟A’等是具体状态，'曾侯乙编钟’是具体环境（Context）。

《深入设计模式》

• 

• 智能手机的按键和开关会根据设备当前状态完成不同行为：

  • 当手机处于解锁状态时， 按下按键将执行各种功能。
  • 当手机处于锁定状态时， 按下任何按键都将解锁屏幕。
  • 当手机电量不足时， 按下任何按键都将显示充电页面。

• 这里是核心 Java 程序库中一些状态模式的示例：

  • javax.faces.lifecycle.LifeCycle#execute() （由 Faces­Servlet控制： 行为依赖于当前 JSF 生命周期的阶段 （状态））

《图说设计模式》

状态模式在工作流或游戏等类型的软件中得以广泛使用，甚至可以用于这些系统的核心功能设计，如在政府OA办公系统中，一个批文的状态有多种：尚未办理；正在办理；正在批示；正在审核；已经完成等各种状态，而且批文状态不同时对批文的操作也有所差异。使用状态模式可以描述工作流对象（如批文）的状态转换以及不同状态下它所具有的行为。