状态模式（State Pattern）。

定义

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

状态模式的核心是封装，状态的变更引起了行为的变更，从外部看起来就好像这个对象对应的类发生了改变一样。

我们先来看看状态模式中的3个角色。

• State——抽象状态角色

接口或抽象类，负责对象状态定义，并且封装环境以实现状态切换。

• ConcreteState——具体状态角色

每一个具体状态必须完成两个职责：本状态的行为管理以及趋向状态处理，通俗的说，就是本状态下要做的事情，以及本状态如何过渡到其他状态。

• Context——环境角色

定义客户端需要的接口，并且负责具体状态的切换。

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

通用源码

我们再来看看状态模式的通用源码，首先来看抽象环境角色，如下所示。

public abstract class State {
	// 定义一个环境角色，提供子类访问
	protected Context context;

	/**
	 * 设置环境角色
	 * 
	 * @param context
	 */
	public void setContext(Context context) {
		this.context = context;
	}

	/**
	 * 行为1
	 */
	public abstract void handle1();

	/**
	 * 行为2
	 */
	public abstract void handle2();
}

抽象环境中声明一个环境角色，提供各个状态类自行访问，并且提供所有状态的抽象行为，由各个实现类实现。具体环境角色如下所示。

public class ConcreteState1 extends State {

	@Override
	public void handle1() {
		// 本状态下必须处理的逻辑
	}

	@Override
	public void handle2() {
		// 设置当前状态为state2
		super.context.setCurrentState(Context.STATE2);
		// 过滤到state2状态，由Context实现
		super.context.handle2();
	}

}
public class ConcreteState2 extends State {

	@Override
	public void handle1() {
		// 设置当前状态为state1
		super.context.setCurrentState(Context.STATE1);
		// 过滤到state1状态，由Context实现
		super.context.handle1();
	}

	@Override
	public void handle2() {
		// 本状态下必须处理的逻辑
	}

}

具体环境角色有两个职责：处理本状态必须完成的任务，决定是否可以过渡到其他状态。我们再来看环境角色，如下所示。

public class Context {
	// 定义状态
	public final static State STATE1 = new ConcreteState1();
	public final static State STATE2 = new ConcreteState2();
	// 当前状态
	private State CurrentState;

	public State getCurrentState() {
		return CurrentState;
	}

	public void setCurrentState(State currentState) {
		CurrentState = currentState;
		// 切换状态
		this.CurrentState.setContext(this);
	}

	/**
	 * 行为委托
	 */
	public void handle1() {
		this.CurrentState.handle1();
	}

	/**
	 * 行为委托
	 */
	public void handle2() {
		this.CurrentState.handle2();
	}
}

环境角色有两个不成文的约束：

• 把状态对象声明为静态常量，有几个状态对象就声明几个静态常量。
• 环境角色具有状态抽象角色定义的所有行为，具体执行使用委托方式。

我们再来看场景类如何执行，如下所示。

public class Client {
	public static void main(String[] args) {
		// 定义环境角色
		Context context = new Context();
		// 初始化状态
		context.setCurrentState(new ConcreteState1());
		// 行为执行
		context.handle1();
		context.handle2();
	}
}

我们已经隐藏了状态的变化过程，他的切换引起了行为的变化。对外来说，我们只看到行为的发生改变，而不用知道是状态变化引起的。

优点

• 结构清晰

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

• 遵循设计原则

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

• 封装性非常好

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

缺点

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

使用场景

• 行为随状态改变而改变的场景

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

• 条件、分支判断语句的替代者

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

注意事项

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

最佳实践

状态间的自由切换，那会有很多种，你要挨个牢记一遍吗？比如电梯的例子，我要一个正常的电梯运行逻辑，规则是开门→关门→运行→停止；还要一个紧急状态（如火灾）下的运行逻辑，关门→停止，紧急状态时，电梯当然不能用了；再要一个维修状态下的运行逻辑，这个状态任何情况都可以，开着门电梯运行？可以！门来回关？可以！永久停止不动？可以！那这怎么实现呢？需要我们把已经有的几种状态按照一定的顺序再重新组装一下，那这个是什么模式？建造者模式，对建造模式+状态模式会起打非常好的封装作用。

更进一步，应该有做过工作流开发，如果不是土制框架，那么就应该有个状态机管理（即使是土制框架也应该有），如一个Activity（节点）有初始化状态（Initialized State）、挂起状态（Suspended State）、完成状态（Completed State）等，流程实例也有这么多状态，那这些状态怎么管理呢？通过状态机（State Machine）来管理，那状态机是什么东西呢？就是我们上面提到的Context类的升级变态BOSS！