状态模式

唯一不变的原则就是变化

一个刚刚设计完毕并诞生的程序，后续必须随着客观世界的改变而进行更新，否则，这个程序会随着时间的流逝而腐烂，最终一无是处。因此，当设计程序时，要时时刻刻想着未来有可能发生的变化，以及如何应对这种变化。而这就是设计模式的核心意义所在。

一个好的程序设计，必须易于扩展。一个坏的程序，当你想扩展的时候，就会发现举步维艰，通常改一处，就会影响其他四五处，且潜在的bug无法预知，随着项目的日益庞大，结果就是，改不动了。。。效率无限趋进于0，最后，程序死亡。这种后续维护所带来的成本是巨大的，以及潜在的bug危险对项目来说也是致命的，同样对于公司的发展也是致命的。

状态模式

允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的行为。

将状态封装为一个类，每个行为都封装到对应的状态内。客户端将每个行为委托给状态类执行，就会产生不同状态执行同一行为的效果不同。当执行完一个行为，客户端的状态发生变化时，就改变客户端的委托对象，达到一个状态变化的效果。

与策略模式

相同点，就是根据组合的对象不同，行为发生了改变。不同点就是，策略模式，是客户端手动指定组合对象，而状态模式，客户端是无法控制状态模式的组合对象的，而是随着操作的不同，上下文环境自动切换组合对象，对客户端来说，行为是自动变化的。

与模版模式

模板方法模式类似于策略模式，但是模版方法的实现类实现部分算法和逻辑，策略模式的实现类实现所有的算法和逻辑，状态模式的实现类可以实现部分逻辑，也可以实现所有算法和逻辑。

但真正的区别在于他们的意图，模板方法模式意图在于提供一个固定的算法框架，策略模式的意图在于通过组合指定方法族的某一个算法，可以实现代码的通用，状态模式的意图在于随着情景的变化，动态的切换其组合的对象实现不同的行为效果。

总结

当你设计的某个类，有一些状态，同一操作在不同的状态下会产生不同的效果，这个时候，就是状态模式登场的时候了。如果不用状态模式，就要用一大堆if...else...进行状态判断，这种不易于阅读和扩展的代码是糟糕的代码。当需求变更来临的时候，代码是要改死人的哦。

抽取变化：变化的是类不同的状态下，操作的不同效果。我们将这种变化部分抽离出来，作为状态类，将每个状态对应的行为封装在状态类中，这样我们只要改变类中组合的状态类，就可以达到状态的改变以及行为的改变。这种代码易于阅读和扩展。