经典的设计模式20——状态模式

---

状态模式

定义：
当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。
结构：
环境角色（context）：也称上下文角色，它定义了客户程序需要的接口，维护一个当前状态，并将与状态相关的操作委托给当前状态对象来处理。
抽象状态（State）：定义一个接口，用以封装环境对象中的特定状态所对应的行为。
具体状态角色（concreteState）：实现抽象状态所对应的行为。
优点：
唯一性，一致性。
缺点：
逻辑分散化。
本质：
根据状态来分离和选择行为状态驱动，由上下文负责。
理解：
将与特定状态相关的行为局部化并且将不同状态的行为分割开来。将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在于某个concreteState中，所以通过定义新的子类可以很容易的增加新的状态和转换。这样做的目的就是消除庞大的条件分支语句。状态模式通过把各种状态转移逻辑分布到State的子类之间，来减少相互间的依赖。当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑用状态模式。
优点：
将所有与某个状态有关的行为放到一个类中，并且可以方便的增加新的状态，只需要改变对象状态即可改变对象的行为。
允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
缺点：
状态模式的使用必然会增加系统类和对象的个数。
状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
状态模式对于开闭原则的支持并不太好。