状态模式:允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类。
这个模式将状态封装成为独立的类,并将动作委托到代表当前对象的对象,这样行为就与拥有状态类解耦了。
从客户的角度来看,对象的行为被完全改变,好像对象是从别的类实例化而来,但实际上我们是使用组合通过简单引用不同的状态对象来造成类改变的假象。
类图:
看到状态模式的类图,如果对策略模式熟悉的人,会发现两者的类图根本是一模一样的。
两个模式的差别在于它们的“意图”。
对状态模式来说,将一群行为封装在状态对象中,context的行为随时可委托给状态对象的人任何一个,当前状态在状态对象中游走改变,以反映Context的内部状态,Context的客户对状态对象不了解,仅有一个State接口的引用,不知道运行时具体是哪个状态类的行为。这样在Context内部不需要放置许多条件判断当前是哪种状态以决定行为这种不优雅的实现。
对策略模式来说,客户通常主动指定Context所要组合的策略对象是哪一个,一般不会轻易修改策略,策略模式只是让我们的设计更具弹性,能够在运行时改变策略,一般来说,策略模式可以想成是继承之外的一种弹性替代方案,如果使用继承来定义一个类的行为,就被这个行为困住,当行为改变时,必然要修改原有的代码,有了策略模式,可以通过组合不同的对象来改变行为,而不需要更改已经写好的代码。
下面举个例子:一个游戏有两个状态start和stop
interface State { public abstract void handle(); }
public class StartState implements State {
public void handle() {
System.out.println("In start state");
}
}
public class StopState implements State {
public void handle() {
System.out.println("In stop state");
}
}
public class Context {
State state;
public void request() {
state.handle();
}
pubblic void setState(State s){
state = s;
}
public State getState() {
return state;
}
}
public class Client {
public static void main(String[] args) {
Context c = new Context();
StartState s1 = new StartState();
StopState s2 = new StartState();
c.setState(s1);
c.request();
c.setState(s2);
c.request();
}
}