设计模式之~状态模式

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

• 能够让程序根据不同的外部情况来做出不同的响应，最直接的方法就是在程序中将这些 可能发生的外部情况全部考虑到，使用if else 语句来进行代码响应选择。但是这种方法对于复杂一点的状态判断，就会显得杂乱无章，容易产生错误,而且增加一个新的状态将会带来大量的修改。

• 这个时候“根据状态决定行为”的状态模式的引入也许是个不错的主意。状态模式可以有效的替换充满在程序中的 if else 语句：将不同条件下的行为封装在一个类里面，再给这些类一个统一的父类来约束他们

结构图：

        状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化

优点：

• 好处是将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。（每个状态类的职责单一明确，易于扩展）

• 将特定的状态相关的行为都放入一个独立对象中，由于所有与状态相关的代码都存在于某个ConcreteState中，所以通过定义新的子类可以很容易地增加新的状态和转换。目的就是为了消除庞大的条件分支语句，大的分支判断会使得它们难以修改和扩展，就像最早说的刻板印刷一样，任何改动和变化都是致命的。

• 状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相互间的依赖。

缺点：

• 状态过多会引起类膨胀(事实上这也是大部分设计模式的通病)。

• 状态模式的结构与实现相对较为复杂，容易造成代码混乱。

• 对于支持状态切换的状态类违反了开闭原则，因为一旦状态修改或者中间要新增状态，则需要修改对应的源代码，否则会出现状态切换错误。

适用场景：

• 当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式了。

• 另外如果业务需求某项业务有多个状态，通常都是一些枚举常量，状态的变化都是依靠大量的多分支判断语句来实现，此时应该考虑将每一种业务状态定义为一个State的子类。这样这些对象就可以不依赖于其他对象而独立变化了，某一天客户需要更改需求，增加或减少业务状态或改变状态流程，都不是困难的事。

状态模式和策略模式对比：

        状态模式和策略模式都能用来消除大量的if/else场景，但是也有本质区别：

• 策略模式中各个策略之间是独立的，相互可以替换的，任意选择其中一个策略就能满足需求，而且是由客户端自己做出选择。而状态模式客户端只能选择初始节点，后续就会自动流转，各个状态是一个整体，不存在可以互相替换的状态。

• 最根本的差异在于策略模式是在求解同一个问题的多种解法，这些不同解法之间毫无关联；状态模式则不同，状态模式要求各个状态之间有所关联，以便实现状态转移。

• 区分这两个模式的关键是看行为是由状态驱动还是由一组算法驱动