设计模式——状态模式

定义

对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。

模板

状态模式包含以下主要角色。
环境（Context）角色：也称为上下文，它定义了客户感兴趣的接口，维护一个当前状态，并将与状态相关的操作委托给当前状态对象来处理。
抽象状态（State）角色：定义一个接口，用以封装环境对象中的特定状态所对应的行为。
具体状态（Concrete State）角色：实现抽象状态所对应的行为。

实例

下面举一个上传过程中状态控制：

状态模式中，UploadController 相当于模块上下文，它持有一个状态变量mAbstractState,并通过该变量的方法实现状态的切换。

如何实现状态转换？
在IState中，以及所有具体实现State中接口都需要传入UploadController作为参数，通过获取Controller的实例来进行状态转换。

优点

1、封装了转换规则。
2、枚举可能的状态，在枚举状态之前需要确定状态种类。
3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。

缺点

1、状态模式的使用必然会增加系统类和对象的个数。
2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
3、状态模式对“开闭原则”的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。

适用场景

1、对象的行为依赖于它的状态（属性）并且可以根据它的状态改变而改变它的相关行为。
2、代码中包含大量与对象状态有关的条件语句

其它实例：
从电商系统订单状态说状态模式！