版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u011815404/article/details/89792150
【概述】
状态模式主要是用于解决对象状态转换的条件表达式过于复杂的情况，其将状态的判断逻辑转移到表示不同状态的一系列类当中，令复杂的逻辑简化。
状态模式允许一个对象在其内部状态改变时改变它的行为，使得这个对象看起来似乎修改了它的类，其根据状态来分离和选择行为，本质是由上下文负责状态驱动。
每个人、事物在不同的状态下会有不同表现（动作），而一个状态又会在不同的表现下转移到下一个不同的状态（State），通常在实现存在状态转移的系统时，会使用到很多的 switch-case 语句、if-else语句，但这种实现方式至少有以下两个问题：
- 当状态数目不是很多的时候，switch-case 可以搞定，但当状态数目很多的时候，维护一大组的 switch-case 语句将是一件异常困难并且容易出错的事情
- 由于状态逻辑和动作实现没有分离，在很多的系统实现中，动作的实现代码直接写在状态的逻辑当中，这使得系统的扩展性和维护性极差
State 模式就是被用来解决上面列出的两个问题的，在 State 模式中将状态逻辑和动作实现进行分离，因此，当一个操作中要维护大量的分支语句，并且这些分支依赖于对象的状态时，常常使用状态模式，将每一个分支都封装到独立的类中。
【UML】
状态模式涉及到了三个角色：
- 抽象状态角色：State，封装与 Context 的一个特定状态相关的行为
- 具体状态角色：Concrete State，每一个子类实现一个与 Context 的一个状态相关的行为
- 上下文角色：Context，维护一个具体状态角色的实例，这个实例定义了当前的状态
【优缺点】
优点：
- 将与特定状态相关的行为局部化，并且将不同状态的行为分割开来
- 消除庞大的条件分支语句，把各种状态转移逻辑分布到State的子类之间，减少了相互间的依赖
- 显式化进行状态转换，为不同的状态引入独立的对象，使得状态的转换变得更加明确，且由于上下文中只有一个变量来记录状态对象，其可以保证上下文不会发生内部状态不一致的状况
缺点：逻辑分散化，状态逻辑分布到诸多的 State 子类中，很难看到整个的状态逻辑图，代码维护较为困难