设计之禅——状态模式
前言
之前我写过一篇策略模式的文章，讲的是如何灵活地改变对象的行为，今天要讲的模式和策略模式非常像，它也是让你设计出如何灵活改变对象行为的一个模式，与策略模式不同的是它是根据自身状态而自行地改变行为，它就是状态模式。
详解
普通实现
首先我们来分析一个实例：现在的游戏基本都有自动打怪做任务的功能，如果让你实现这个功能你会怎么做呢？
本篇讲解的是状态模式，当然首先应该分析其应有状态和行为，下面是我画的一个简单的状态图：
椭圆代表的是所处状态，指引线代表执行的行为。一开始角色处于初始状态，什么也不做，当玩家开启自动任务功能时，角色就自动的接受任务，当接到杀怪的任务后，发现周围没有怪，就把“初始状态”改为“未发现怪物”状态并开始四处游走寻找怪物，走啊走，走啊走，发现了目标怪物就将状态修改为“发现怪物”，然后开始攻击打怪，直到杀怪数量达到任务指定数量后，就停止打怪并将状态修改为“任务达成”状态，最后回到接任务那里提交任务，角色状态又重置为初始状态（这里只是为了方便理解该模式，不要太纠结功能细节）。不难发现，在该实例中，我们包含了四个状态和四个行为，任何一个行为是随时都有可能进行的，但是其表现结果却会因为状态的不同而有不一样的结果，按照我们面向过程的编程方式也是非常容易实现的：
public class Character {
// 停止
private final static int STOP = 0;
// 附近有怪
private final static int HASMONSTER = 1;
// 附近没有怪
private final static int NOMONSTER = 2;
// 任务条件达成
private final static int MISSIONCLEAR = 4;
// 当前状态
private int state = STOP;
// 还需杀怪数量
private int count = 0;
public void accept(int count) {
if (state == STOP) {
this.count = count;
state = NOMONSTER;
// move to find the monster
move();
} else if (state == HASMONSTER) {
System.out.println("Sorry!You are doing the task,so you can't accept the new task!!");
} else if (state == NOMONSTER) {
System.out.println("Sorry!You are doing the task,so you can't accept the new task!!");
} else if (state == MISSIONCLEAR) {
System.out.println("Sorry!You must submit the current task!");
}
}
private void move() {
if (state == STOP) {
System.out.println("Moving....");
state = HASMONSTER;
attack();
} else if (state == HASMONSTER) {
System.out.println("Moving to find new monster");
attack();
} else if (state == NOMONSTER) {
System.out.println("Moving to find monster");
state = HASMONSTER;
attack();
} else if (state == MISSIONCLEAR) {
System.out.println("Moving to submit");
submit();
}
}
private void attack() {
}
private void submit() {
}
}最后两个方法我没有给出具体实现，相信难不倒你，当全部实现后角色就能自动接任务打怪了：
Accept the task.Need to kill monster:10
Moving to find monster
need to kill:9
need to kill:8
need to kill:7
need to kill:6
need to kill:5
need to kill:4
need to kill:3
need to kill:2
need to kill:1
need to kill:0
Moving to submit
Congratulations on completing the task!不过，功能虽然实现了，但是这样写代码冗长不说，还非常难于理解维护，想象一下这里只假设了4种状态，当如果有非常多的状态，那就是满篇的if else了，而且如果未来需要增加新的状态，那么当前的实现无疑是违反了open-close原则的，我们没有封装变化的那部分。那应该如何做呢？这就需要我们的状态模式了。
使用状态模式重构代码
往下看之前，不妨先仔细思考一下，既然该功能中状态是会随时改变的，而行为又会受到状态的影响，那何不将状态抽离出来成为一个体系呢？比如定义一个状态接口（为什么这里需要定义所有的行为方法呢？）：
public interface State {
void accept(int count);
void move();
void attack();
void submit();
}那么角色类中就可以如下定义了：
public class Character {
// 当前状态
private State current = new StopState(this);
// 所需杀怪数量
private int count = 0;
public void accept(int count) {
// 注意这里不能直接将值赋给成员变量
current.accept(count);
}
public void move() {
current.move();
}
public void attack() {
current.attack();
}
public void submit() {
current.submit();
}
public void killOne() {
this.count--;
}
public void setCurrent(State current) {
this.current = current;
}
public void setCount(int count) {
this.count = count;
}
public State getCurrent() {
return current;
}
public int getCount() {
return count;
}
}相比较之前，新的类只保留了当前状态，并增加了getter和setter方法，而角色的行为则全都委托给了具体的状态类来实现，那具体的状态类应该如何实现呢？
// 初始状态
public class StopState implements State {
private Character c;
public StopState(Character c) {
this.c = c;
}
@Override
public void accept(int count) {
c.setCount(count);
c.setCurrent(new NoMonsterState(c));
c.move();
}
@Override
public void move() {
System.out.println("Moving....");
c.setCurrent(new HasMonsterState(c));
c.attack();
}
@Override
public void attack() {
System.out.println("Sorry!You must accept the task!");
}
@Override
public void submit() {
System.out.println("You don't have task to submit!");
}
}
// 附近没有怪物
public class NoMonsterState implements State {
private Character c;
public NoMonsterState(Character c) {
this.c = c;
}
@Override
public void accept(int count) {
System.out.println("Sorry!You are doing the task,so you can't accept the new task!!");
}
@Override
public void move() {
System.out.println("Moving to find monster!");
c.setCurrent(new HasMonsterState(c));
c.attack();
}
@Override
public void attack() {
c.move();
}
@Override
public void submit() {
System.out.println("Please complete the task!");
}
}这里我也只给出了两个实现类，其它的相信你能很容实现它们。通过状态模式重构后，代码清晰了很多，没有满屏的if else，角色也能够根据当前所处的状态表现出相应的行为，同时如果需要增加新的状态时，只需要实现State接口就行了，看起来相当完美。但是，没有什么模式是完美的，使用状态模式的缺点我们很容易发现，原来一个类就能解决的，现在裂变为了四个类，系统结构复杂了很多，但这样的牺牲是非常有必要和值得的。
思考
刚刚我们已经实现了状态模式，但是还有个细节问题不知你注意到了没有？比如：
public void move() {
System.out.println("Moving....");
c.setCurrent(new HasMonsterState(c));
c.attack();
}在我的实现中，都是由状态来控制下一个状态是什么，这样状态之间就形成了强依赖，当然你可以将状态转换放到context（Character）类中，不过这种更适合状态转换是固定的，而在我们这个例子中，状态的变更是动态的。还需要注意的是我这里调用 c.setCurrent(new HasMonsterState©)时，状态是硬编码传入的，这样当系统进化时可能就需要更改此处的代码，如何解决这种情况呢？在《Head First设计模式》书中有提到，在Context类中定义所有的状态并提供getter方法，这里则调用getter获取后再传入，但区别只在于是context类还是状态类对修改封闭：
c.setCurrent(c.getHasMonsterState());对此我有点疑问，即使使用getter获取，那未来系统进化导致状态的改变后难道不需要修改getter方法名么？
总结
状态模式允许对象在内部状态改变时改变它的行为，如果需要在多个对象间共享状态，那么只需要定义静态域即可。
状态模式与策略模式具有相同的类图，但它们本质的意图是不同的。前者是封装基于状态的行为，并将行为委托到当前的状态，用户不需要知道有哪些状态；而后者是将可以互换的行为封装起来，然后使用委托，由客户决定需要使用哪种行为，客户需要知道所有的行为类。