概述:

1.解决系统中复杂对象的状态转化

2.不同状态下行为的封装。

场景：当系统中某个对象存在多个状态，这些状态之间可以进行转换，而且对象在不同状态下行文不相同可以使用状态模式。

状态模式将一个对象的状态从该对象分离出来，封装到专门的状态类中，使得状态可以灵活变化。

状态模式的结构：

1> Context(环境类)  环境类又称为上下文类，它是拥有多种状态的对象。由于环境类的状态存在多样性且不同状态下镀锡那个的行为有所不同，因此将状态独立出去形成单独的状态类。在环境雷总维护一个抽象状态类State的实例，这个实例定义当前状态。环境类和状态类都可以负责状态转化。

2>State (抽象状态类) 不同状态下具有相同的行为可以封装到抽象状态类。抽象状态类封装了所有具体状态下的行为---缺点

4.由状态类负责状态转化

缺点：

1、状态模式的使用必然会增加系统类和对象的个数。 

2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。

 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。

使用场景

策略模式做的都是同一件事，例如聚合支付平台，有支付宝、微信支付、银联支付，虽然策略不同，但最终做的事情都是支付

状态模式封装了对象的状态，而策略模式封装算法或策略

例如：审批流，存取款   行为比较少，但是会触发很多状态

状态模式与策略模式的区别

状态模式和策略模式的 UML 类图架构几乎完全一样，但两者的应用场景是不一样的。策略模式的多种算法行为择其一都能满足，彼此之间是独立的，用户可自行更换策略算法，而状态模式的各个状态间存在相互关系，彼此之间在一定条件下存在自动切换状态的效果，并且用户无法指定状态，只能设置初始状态。

积分商城使用状态模式

分析----积分商城的状态和行为

状态流转

状态和应为的对应关系

状态类需要有哪些方法

context：

抽象状态类:

初始状态：

待确认状态：

确认状态：