1 前言
有时一个对象的行为取决于一或多个动态变化的属性（状态），这样的对象称为有状态(stateful)对象，其对象状态是从事先定义好的一系列值中取出。当这样的对象与外部事件产生互动时，内部状态就会改变，对象行为也随之变化。
在UML中可使用状态图描述对象状态的变化。在状态模式中，创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。
2 定义
该模式下，类的行为基于其状态而改变。即允许一个对象在其内部状态改变时，改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象(Objects for States)，状态模式是一种对象行为型模式。
3 架构
3.1 Context-环境类
拥有状态的对象，环境类有时可以充当状态管理器(State Manager)，在环境类中对状态进行切换操作。
3.2 State-抽象状态类
可以是抽象类，也可是接口，不同状态类就是继承这个父类的不同子类，状态类的产生是由于环境类存在多个状态，同时还满足：这些状态经常需要切换，在不同状态下对象行为不同。
3.3 ConcreteState-具体状态类
角色：状态服务方，状态客户方，特定状态服务方。
通过特定状态服务方，将原来属于状态服务方的多状态模式，转化为单状态模式，降低了状态服务的逻辑复杂度，提高状态服务的可扩展性。
4 意义
解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
状态模式的关键是引入了一个抽象类来专门表示对象的状态 - 抽象状态类。而对象的每种具体状态类都继承该类，并在不同具体状态类中实现不同状态的行为，包括各种状态之间的转换。
将不同对象下的行为单独提取出来，封装在具体的状态类，使得环境类对象在其内部状态改变时可以改变它的行为，对象看起来似乎修改了它的类，而实际上是由于切换到具体状态类实现。
由于环境类可设置为任一具体状态类，因此它针对抽象状态类进行编程，在程序运行时可以将任一具体状态类的对象设置到环境类中，从而使得环境类可以改变内部状态，并且改变行为。
5 优点
- 封装了转换规则
- 枚举可能的状态，在枚举状态之前需要确定状态种类
- 将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
- 允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
- 可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
6 缺点
- 必增加系统类和对象的个数
- 结构与实现都较为复杂，若使用不当将导致程序结构和代码的混乱
- 对"开闭原则"支持不太好，对可切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码
在DDD中，为所有状态创建单独的类会使系统变得复杂。对于实体状态类来说，有些行为来自于自身，有些行为继承自抽象基类，这一方面在子类和父类之间形成紧耦合，另一方面使代码的可读性变差。但是，使用枚举则非常简单，与通过状态模式来创建标准类型相比，枚举可能是更好的方法。这里我们同时得到了两种方法的好处：
- 获得了一个非常简单的标准类型
- 又能有效地表示当前的状态
7 适用场景
代码中包含大量与对象状态有关的条件语句：
- 对象的行为依赖于它的状态（属性）并且可以根据它的状态改变而改变它的相关行为
- 代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为，而且这些条件对应于对象的各种状态
-
如何解决
将各种具体的状态类抽象出来。
-
关键代码
通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。状态模式和命令模式一样，也可以用于消除 if...else 等条件选择语句。
在行为受状态约束的时候使用状态模式，而且状态不超过 5 个。
8 业务应用
在工作流或游戏等类型的软件中得以广泛使用，甚至可以用于这些系统的核心功能设计，如在政府OA办公系统中，一个批文的状态有多种：尚未办理；正在办理；正在批示；正在审核；已经完成等各种状态，而且批文状态不同时对批文的操作也有所差异。使用状态模式可以描述工作流对象（如批文）的状态转换以及不同状态下它所具有的行为。
9 案例
9.1 案例一
- State 接口
- 实现 State 接口的实体状态类
设计模式实战-状态模式(State Pattern) - Context：带有某状态的类
设计模式实战-状态模式(State Pattern) - StatePatternDemo，测试类使用Context 和状态对象展示在状态改变时的行为变化
设计模式实战-状态模式(State Pattern)
9.2 电商订单状态流转改造
电商平台购物基本的流程：
- 搜索商品
- 进入商品列表页面，点击商品
- 进入商详页，了解商品之后，将商品加入购物车
- 进入购物车页面，确认购买的商品之后，点击结算按钮
- 进入结算页面，选择收货地址，配送方式等，点击支付按钮
- 进入支付页面，进行订单支付，支付完成
- 进入自己的订单列表页，可以看到自己刚刚下的订单。
提交一个订单后，订单在电商系统后台，会经历很多状态流转，直至到订单完结状态（妥投，取消，删除等）。订单状态的流转，涉及电商系统交易，仓储，配送等环节。不同品类商品的订单，订单状态流转差异也较大，比如虚拟商品，就不涉及仓储，配送等环节，状态流转简化不少。
订单的每个状态，前端支持用户行为不同：
- 未支付：支付，取消，删除
- 已支付：催单
- 已发货：催单
- 已妥投：点评，删除
- 已删除：用户就看不到了，所以不支持任何操作
9.2.1 业务挑战
订单的状态流转，受商品和业务影响，复杂多变，简化订单特定状态下的业务处理逻辑，提高系统对状态的高扩展性，是状态模式的核心意义。
功能限制，我们的重点是讲解状态模式，所以对实现的功能模块需要进行一定的简化。我们只关注以上五个订单状态（未支付，已支付，已发货，已妥投，已删除）和三个订单相关的操作（支付，催单，删除）。
9.2.2 普通实现
缺陷
每个方法都要考虑订单各个状态，业务逻辑杂糅，若有一个状态需调整，这些方法基本都受影响，若要增加一个新订单状态，上面方法都要相应修改，扩展性差，严重违背开闭原则：比如 pay 接口实现，很复杂，支付功能需要考虑所有状态 case 该如何处理，而每个状态实际处理过程还大不相同。
9.2.3 状态模式重构
状态服务类、抽象类、状态具体服务类
10 扩展
-
共享状态
在有些情况下多个环境对象需共享同一状态，若期望在系统中实现多个环境对象实例共享一个或多个状态对象，那么需要将这些状态对象定义为环境的静态成员对象。
10.1 简单状态模式
状态都相互独立，状态之间无须进行转换的状态模式，这是最简单的一种状态模式。
每个状态类都封装与状态相关的操作，无需关心状态切换，可在客户端直接实例化状态类，然后将状态对象设置到环境类。
遵循“开闭原则”，在客户端可以针对抽象状态类进行编程，而将具体状态类写到配置文件中，同时增加新的状态类对原有系统也不造成任何影响。
10.2 可切换状态的状态模式
大多数的状态模式都是可切换状态的状态模式，在实现状态切换时，在具体状态类内部需要调用环境类Context的setState()方法进行状态的转换操作，在具体状态类中可以调用到环境类的方法，因此状态类与环境类之间通常还存在关联关系或者依赖关系。通过在状态类中引用环境类的对象来回调环境类的setState()方法实现状态的切换。在这种可以切换状态的状态模式中，增加新的状态类可能需要修改其他某些状态类甚至环境类的源代码，否则系统无法切换到新增状态。
11 总结
状态模式允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象，状态模式是一种对象行为型模式。
状态模式包含三个角色：环境类又称为上下文类，它是拥有状态的对象，在环境类中维护一个抽象状态类State的实例，这个实例定义当前状态，在具体实现时，它是一个State子类的对象，可以定义初始状态；抽象状态类用于定义一个接口以封装与环境类的一个特定状态相关的行为；具体状态类是抽象状态类的子类，每一个子类实现一个与环境类的一个状态相关的行为，每一个具体状态类对应环境的一个具体状态，不同的具体状态类其行为有所不同。
适用场景
- 对象的行为依赖于它的状态（属性）并且可以根据它的状态改变而改变它的相关行为
- 代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，使客户类与类库之间的耦合增强。
- https://www.bilibili.com/read/cv16247154