《设计模式之禅》之状态模式

一、状态模式的定义

当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。

1.状态模式中的3个角色

(1)State–抽象状态角色
接口或抽象类，负责对象状态定义，并且封装环境角色以实现状态切换。

(2)ConcreteState–具体状态角色
每一个具体状态必须完成两个职责:本状态的行为管理以及趋向状态处理，通俗地讲，就是本状态下要做的事情，以及本状态如何过渡到其他状态。

(3)Context–环境角色
定义客户端需要的接口，并且负责状态的切换。

状态模式相对来说比较复杂，它提供了一种对物质运动的另一个观察视角，通过状态变更促使行为的变化，就类似水的状态变更一样，一碗水的初始状态是液态，通过加热转变为气态，状态的改变同时也引起体积的扩大，然后就产生了一个新的行为:鸣笛或顶起壶盖，瓦特就是这么发明蒸汽机的。

二、状态模式的应用

1.状态模式的优点

(1)结构清晰

避免过多的switch…case或者if..else语句的使用，避免了程序的复杂性，提高系统的可维护性。

(2)遵循设计原则

很好地体现了开闭原则和单一职责原则，每个状态都是一个子类，你要增加状态就要增加子类，你要修改状态，你只修改一个子类就可以了。

(3)封装性非常好

这也是状态模式的基本要求，状态变换放置到类的内部来实现，外部的调用不用知道类内部如何实现状态和行为的变换。

2.状态模式的缺点

子类会太多，也就是类膨胀。如果一个事物有很多个状态也不稀奇，如果完全使用状态模式就会有太多的子类，不好管理，这个需要大家在项目中自己衡量。其实有很多方式解决这个状态问题，如在数据库中建立一个状态表，然后根据状态执行相应的操作，这个也不复杂，看大家的习惯和嗜好。

3.状态模式的使用场景

(1)为随状态改变而改变的场景

这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行下相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。

(2)条件、分支判断语句的替代性

在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰，逻辑混乱，使用状态模式可以很好地避免这一问题，它通过扩展子类实现了条件的判断处理。

4.状态模式的注意事项

状态模式适用于当某个对象在它的状态发生改变时，它的行为也随着发生比较大的变化，也就是说在行为受状态约束的情况下可以使用状态模式，而且使用时对象的状态最好不要超过5个。

三、最佳实践

如工作流开发，如果不是土制框架，那么就应该有个状态机管理(即使是土制框架也应该有)，如一个Activity(节点)有初始化状态(Initialized State)、挂起状态(Suspended State)、完成状态(Completed State)等，流程实例也有这么多状态，那这些状态怎么管理呢？通过状态机来管理。
代码示例地址如下:
https://github.com/developers-youcong/DesignPatternPractice/tree/master/State