设计模式之状态模式

DesignPattern之State

1. Definition

==状态模式允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类==。

这个模式将封装成为独立的类，并将动作委托到代表当前状态的对象，从而使行为会随着内部状态的改变而改变。

“看起来好像修改了它的类”的意思是：从客户的角度看来：如果说你使用的对象能完全改变它的行为，那么你就会觉得，这个对象实际上是从别的类实例化而来的。然而，==这是在使用状态模式，通过简单引用不同的状态对象来造成类改变的假象==。

UML（Head First Design Pattern p410）

Context: 可以拥有一些内部状态，里面有一个request方法，Context在不同状态下调用request方法发生的行为不同。不管是什么时候，只要调用request方法去，就会被委托到状态来处理。

State接口： 定义了一个所有具体的状态的共同接口，任何状态都实现了这个相同的接口，这样一来，状态之间可以互相替换。

ConcreteState： 实现了State接口，处理来自Context的请求。每一个ConcreteState都提供了它自己对于请求的实现。所以当Context改变状态时行为也跟着改变。

个人理解：

Context在不同状态下调用request方法会产生不同的行为，所以调用这个方法必须得确定当前Context的状态是什么，才能产生正确的行为。

Too young too naive的设计：在request方法里加一大堆条件判断语句：

~~~java

if（State a） {
// Operation A
} else if (State b) {
// Operation B
} else {
// Operation C
}

~~~

或者用switch语句。这样做的画，设计就绑死在实现上了，如果改了需求（比如说在State a下要执行Operation B），那么就得修改源码，需求一变动，源码就得不断修改。显然这样做十分不符合OCP。

那么可以换个角度思考一下，既然Context在不同的状态下对request方法有不同的行为，何不把变化的部分给封装出来。把request方法的方法委托给状态去实现，不同的状态handle request的实现都不同，然后用Context去==组合==不同的状态。这样就能省去了在request方法里对不同状态的判断的条件语句，因为Context一旦转换状态，就组合它所需要的状态，状态的判断已经通过组合新状态的形式无形中完成了，在某个特定的状态下request方法由特定的实现。

2. Example

状态机如下：

|----------|
|          |
| Sold Out |<---------------------------------------|
|          |                                        |
|----------|                                    [Num == 0]
|
|
|-----------|                             |-------------|                       |-------|        |
|           |----[Insert Quarter]-------> |             |                       |       |        |
| No Quarter|                             | Has Quarter |-----[turn crank]----> | Sold  |--------|
|           |<---[eject Quarter]--------- |             |                       |       |        |
|-----------|                             |             |<--------|             |-------|        |
|-------------|         |                          [Num > 0]
|                              |
-------------------------------|

Context：

GumballMachine

~~~java

package state;

public class GumballMachine {

private State soldOutState;
private State noQuarterState;
private State hasQuarterState;
private State soldState;

private State state = soldOutState;
private int count = 0;

public GumballMachine(int gumballNum) {
this.soldOutState = new SoldOutState(this);
this.noQuarterState = new NoQuarterState(this);
this.hasQuarterState = new HasQuarterState(this);
this.soldState = new SoldState(this);
this.count = gumballNum;

if (gumballNum > 0) {
this.state = noQuarterState;
}
}

public void insertQuarter() {
this.state.insertQuarter();
}

public void ejectQuarter() {
this.state.ejectQuarter();
}

public void turnCrank() {
this.state.turnCrank();
this.state.dispense();
}

void setState(State state) {
this.state = state;
}

public void releaseBall() {
System.out.println("A gumball is coming!!!\n");
if (this.count > 0) {
this.count -= 1;
}
}

public State getSoldOutState() {
return soldOutState;
}

public void setSoldOutState(State soldOutState) {
this.soldOutState = soldOutState;
}

public State getNoQuarterState() {
return noQuarterState;
}

public void setNoQuarterState(State noQuarterState) {
this.noQuarterState = noQuarterState;
}

public State getHasQuarterState() {
return hasQuarterState;
}

public void setHasQuarterState(State hasQuarterState) {
this.hasQuarterState = hasQuarterState;
}

public State getSoldState() {
return soldState;
}

public void setSoldState(State soldState) {
this.soldState = soldState;
}

public int getCount() {
return count;
}

public void setCount(int count) {
this.count = count;
}

public State getState() {
return state;
}

@Override
public String toString() {
return "Gumball amonut : " + this.count + "\nMachine State : "
+ this.state + "\n";
}
}

~~~

abstact State ：

state

~~~java

package state;

public abstract class State {

protected GumballMachine machine;

public State(GumballMachine machine) {
this.machine = machine;
}

public abstract void insertQuarter();

public abstract void ejectQuarter();

public abstract void turnCrank();

public abstract void dispense();
}

~~~

Concrete State:

NoQuarter

,

HasQuarter

,

Sold

,

SoldOut

NoQuarter

~~~java

package state;

public class NoQuarterState extends State {

public NoQuarterState(GumballMachine machine) {
super(machine);
}

@Override
public void insertQuarter() {
System.out.println("u have inserted a quarter!\n");
this.machine.setState(this.machine.getHasQuarterState());
}

@Override
public void ejectQuarter() {
System.out.println("u haven't inserted a quarter!\n");
}

@Override
public void turnCrank() {
System.out.println("Sorry there's no quarter...\n");
}

@Override
public void dispense() {
System.out.println("u need to pay first!\n");
}

public String toString() {
return "No Quarter";
}

}

~~~

HasQuarter

~~~java

package state;

public class HasQuarterState extends State {

public HasQuarterState(GumballMachine machine) {
super(machine);
}

@Override
public void insertQuarter() {
System.out.println("Can not insert another quarter!\n");
}

@Override
public void ejectQuarter() {
System.out.println("Quarter returning...\n");
this.machine.setState(this.machine.getNoQuarterState());
}

@Override
public void turnCrank() {
System.out.println("u turned...\n");
this.machine.setState(this.machine.getSoldState());
}

@Override
public void dispense() {
System.out.println("No gumball dispensed!\n");
}

public String toString() {
return "Has Quarter";
}

}

~~~

Sold

~~~java

package state;

public class SoldState extends State {

public SoldState(GumballMachine machine) {
super(machine);
}

@Override
public void insertQuarter() {
System.out.println("Plz wait, we are giving u a gumball!\n");
}

@Override
public void ejectQuarter() {
System.out.println("Sorry, u have already turned the crank!\n");
}

@Override
public void turnCrank() {
System.out.println("Can not turn the crank twice!\n");
}

@Override
public void dispense() {
this.machine.releaseBall();
if (this.machine.getCount() > 0) {
this.machine.setState(this.machine.getNoQuarterState());
} else {
System.out.println("Oops, out of gamballs...\n");
this.machine.setState(this.machine.getSoldOutState());
}
}

public String toString() {
return "Sold";
}

}

~~~

SoldOut

~~~java

package state;

public class SoldOutState extends State {

public SoldOutState(GumballMachine machine) {
super(machine);
}

@Override
public void insertQuarter() {
System.out.println("Sorry, u can not insert a quarter. The machine is sold out!\n");
}

@Override
public void ejectQuarter() {
System.out.println("Sorry, u haven't inserted a quarter yet\n");
}

@Override
public void turnCrank() {
System.out.println("Sorry the machine is sold out!\n");
}

@Override
public void dispense() {
System.out.println("Sorry the machine is sold out! No gumballs dispensed...\n");
}

public String toString() {
return "SoldOut";
}
}

~~~

Test

~~~java

package state;

public class TestGumballMachine {

public static void main(String[] args) {

GumballMachine machine = new GumballMachine(5);

System.out.println(machine);

System.out.println("-->Insert a quarter");
machine.insertQuarter();
System.out.println(machine);

System.out.println("-->Turn the crank");
machine.turnCrank();

System.out.println(machine);

}

}

~~~

Result:

~~~java

Gumball amonut : 5
Machine State : No Quarter

-->Insert a quarter
u have inserted a quarter!

Gumball amonut : 5
Machine State : Has Quarter

-->Turn the crank
u turned...

A gumball is coming!!!

Gumball amonut : 4
Machine State : No Quarter

~~~

分析

仅以操作

insertQuarter

来分析，GumballMachine在不同状态下对这个操作的实现不同：

NoQuarter状态：可以insert Quarter，打印一句话

"u have inserted a quarter!\n"

,GumballMachine状态转到HasQuarter

HasQuarter状态：不能再insert Quarter了—打印一句话：

"Can not insert another quarter!\n"

Sold状态：正在出Gumball，也不能insert Quarter，—-打印一句话

"Plz wait, we are giving u a gumball!\n"

SoldOut状态：也不能insert Quarter，—-打印一句话

"Sorry, u can not insert a quarter. The machine is sold out!\n"

如果不采用状态模式，那么久得在insertQuarter里加条件判断语句来判断当前状态，前面已经说过，这样设计不符合OCP，很不合理。

采用状态模式后，Gumballm类组合了一个抽象的State：

~~~java

private State state = soldOutState;

~~~

可以在GumballMachine这个类里看到

~~~java

public void insertQuarter() {
this.state.insertQuarter();
}

~~~

当调用GumballMachine的insertQuarter方法时，实际上是委托给它的状态去实现；再观察上面四个具体的状态类，每个类对这个方法的实现都不相同。在转换状态的时候，通过：

~~~java

void setState(State state) {
this.state = state;
}

~~~

来组合不同的状态，从而达到转换状态的目的，也省掉了大段大段的判断状态的条件语句。

状态模式和策略模式

仔细观察不难发现，状态模式和策略模式的UMl图完全一样，这两个模式的差别在于他们的意图

状态模式

将一群行为封装在状态对象中，contex的行为随时可委托到那些状态对象中的一个。随着时间的流逝，当前状态在状态对象集合中游走改变，以反映出context内部的状态。因此，context的行为也会跟着改变。但是context的客户对于状态对象理解不多，甚至根本是浑然不觉。

一般把状态模式想成是不用在context中放置许多条件判断的替代方案。通过将行为包装进状态对象中，可以通过在context中简单的改变状态对象（组合不同的状态对象）来改变context的行为。

策略模式

对策略模式而言，客户通常主动指定context所要组合的策略对象是哪一个。

一般来说，我们把策略模式想成是除了继承之外的一种弹性替代方案。如果使用继承定义了一个类的行为，将会被这个行为困住，甚至想要修改它都难。但使用了策略模式，可以通过组合不同的对象来改变行为。

对状态模式的思考

在个别的状态中封装状态行为，结果就是：增加这个设计中类的数目。这就是为了要获取弹性而付出的代价，这算是状态模式的缺点。

但是状态模式的设计时绝对值得的，因为真正重要的是==暴露给客户的类的数目==，而我们有办法将这些额外的状态类全都隐藏起来。（在上面例子的测试类中并没有出现任何状态类）。

如果不采用状态模式，不将这些状态封装在不同的对象中，就会得到巨大的、整块的条件语句。这会让代码变得十分不容易维护和理解。通过使用许多状态对象，可以让状态变得很干净，在以后理解和维护它们时，可以省下许多功夫。

另外，状态类客户还可以被多个context实例共享