一.定义

    当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。 状态模式相对来说比较复杂，它提供了一种对物质运动的另一个观察视角。

二.类图

• State抽象状态角色。接口或抽象类，负责对象状态定义，并且封装环境角色以实现状态切换。
• ConcreteState具体状态角色。每一个具体状态必须完成两个职责：本状态的行为管理以及趋向状态管理，通俗的说，就是本状态下要做的事情，以及本状态如何过渡到其他状态。
• Context环境角色。定义客户端需要的接口，并且负责具体状态的切换。环境角色有两个不成文的约束：
  • 把状态对象声明为静态常量，有几个状态对象就声明几个静态常量。
  • 环境角色具有状态抽象角色定义的所有行为，具体执行使用委托方式。

三.优点

• 结构清晰。避免过多的swich...case或者if...else语句的使用，避免了程序的复杂性，提高了系统的可维护性。
• 遵循设计原则。很好的体现了开闭原则和单一职责原则，每个状态都是一个子类。
• 封装性非常好。这是状态模式的基本要求，状态变换放置到类的内部来实现，外部的调用不需要知道类内部如何实现状态和行为的变换。

四.缺点

    状态过多，会造成类膨胀问题。

五.使用场景

• 行为随状态改变而改变的场景。这是状态模式的根本出发点，例如权限设计。
• 条件、分支判断语句的替代者。

六.注意事项

• 在行为受约束的情况下可以使用状态模式，而且使用时对象的状态最好不要超过5个。
• 实际项目中，状态行为切换逻辑一般不是单向闭环，而是蜘蛛网结构，某个状态可能会向其他多种状态转换。