1. 概述
当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。
2. 解决的问题
主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同的一系列类当中，可以把复杂的逻辑判断简单化。
3. 模式中的角色
3.1 上下文环境（Context）：它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的Concrete State对象来处理。
3.2 抽象状态（State）：定义一个接口以封装使用上下文环境的的一个特定状态相关的行为。
3.3 具体状态（Concrete State）：实现抽象状态定义的接口。
类图
结构图
状态模式实例类图
状态模式实例结构图
5. 模式总结
5.1 优点
5.1.1 状态模式将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。
5.1.2 所有状态相关的代码都存在于某个ConcereteState中，所以通过定义新的子类很容易地增加新的状态和转换。
5.1.3 状态模式通过把各种状态转移逻辑分不到State的子类之间，来减少相互间的依赖。
5.2 缺点
5.2.1 导致较多的ConcreteState子类
5.3 适用场景
5.3.1 当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式来。
5.3.2 一个操作中含有庞大的分支结构，并且这些分支决定于对象的状态。
详细代码请参考我的git：https://github.com/wzyxidian/DesignModel.git