状态模式是一种行为设计模式。适用于当对象的内在状态改变它自身的行为时。
如果想基于对象的状态来改变自身的行为,通常利用对象的状态变量及if-else条件子句来扮演针对对象的不同行为。状态模式Context(环境)和State(状态)分离的方式既保证状态与行为的联动变化,又使得这种变化是条理明晰且松耦合的。
状态模式的核心是封装, 状态的变更引起了行为的变更, 从外部看起来就好像这个对象
我们先来看看状态模式中的3个角色。
● State——抽象状态角色
接口或抽象类, 负责对象状态定义, 并且封装环境角色以实现状态切换。
● ConcreteState——具体状态角色
每一个具体状态必须完成两个职责: 本状态的行为管理以及趋向状态处理, 通俗地说,就是本状态下要做的事情, 以及本状态如何过渡到其他状态。
● Context——环境角色
具体状态
具体环境角色有两个职责: 处理本状态必须完成的任务, 决定是否可以过渡到其他状态。 我们再来看环境角色。
具体环境角色
环境角色有两个不成文的约束:
● 把状态对象声明为静态常量, 有几个状态对象就声明几个静态常量。
● 环境角色具有状态抽象角色定义的所有行为, 具体执行使用委托方式。
我们再来看场景类如何执行, 如代码清单26-17所示。
看到没? 我们已经隐藏了状态的变化过程, 它的切换引起了行为的变化。 对外来说, 我们只看到行为的发生改变, 而不用知道是状态变化引起的。
状态模式的优点
● 结构清晰
避免了过多的switch...case或者if...else语句的使用, 避免了程序的复杂性,提高系统的可维护性。
● 遵循设计原则
很好地体现了开闭原则和单一职责原则, 每个状态都是一个子类, 你要增加状态就要增加子类, 你要修改状态, 你只修改一个子类就可以了。
● 封装性非常好
这也是状态模式的基本要求, 状态变换放置到类的内部来实现, 外部的调用不用知道类内部如何实现状态和行为的变换。
状态模式既然有优点, 那当然有缺点了。 但只有一个缺点, 子类会太多, 也就是类膨胀。 如果一个事物有很多个状态也不稀奇, 如果完全使用状态模式就会有太多的子类, 不好管理, 这个需要大家在项目中自己衡量。 其实有很多方式可以解决这个状态问题, 如在数据库中建立一个状态表, 然后根据状态执行相应的操作, 这个也不复杂, 看大家的习惯和嗜好了。
● 行为随状态改变而改变的场景
这也是状态模式的根本出发点, 例如权限设计, 人员的状态不同即使执行相同的行为结果也会不同, 在这种情况下需要考虑使用状态模式。
● 条件、 分支判断语句的替代者
在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰, 逻辑混乱, 使用状态模式可以很好地避免这一问题, 它通过扩展子类实现了条件的判断处理。
状态模式适用于当某个对象在它的状态发生改变时, 它的行为也随着发生比较大的变化, 也就是说在行为受状态约束的情况下可以使用状态模式, 而且使用时对象的状态最好不要超过5个。
如果想基于对象的状态来改变自身的行为,通常利用对象的状态变量及if-else条件子句来扮演针对对象的不同行为。状态模式Context(环境)和State(状态)分离的方式既保证状态与行为的联动变化,又使得这种变化是条理明晰且松耦合的。
状态模式的核心是封装, 状态的变更引起了行为的变更, 从外部看起来就好像这个对象
对应的类发生了改变一样。 状态模式的通用类图如图。
我们先来看看状态模式中的3个角色。
● State——抽象状态角色
接口或抽象类, 负责对象状态定义, 并且封装环境角色以实现状态切换。
● ConcreteState——具体状态角色
每一个具体状态必须完成两个职责: 本状态的行为管理以及趋向状态处理, 通俗地说,就是本状态下要做的事情, 以及本状态如何过渡到其他状态。
● Context——环境角色
定义客户端需要的接口, 并且负责具体状态的切换。
状态模式相对来说比较复杂, 它提供了一种对物质运动的另一个观察视角, 通过状态变更促使行为的变化, 就类似水的状态变更一样, 一碗水的初始状态是液态, 通过加热转变为气态, 状态的改变同时也引起体积的扩大, 然后就产生了一个新的行为: 鸣笛或顶起壶盖,瓦特就是这么发明蒸汽机的。 我们再来看看状态模式的通用源代码
抽象状态角色
public abstract class State {
//定义一个环境角色, 提供子类访问
protected Context 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() {
//设置当前状态为stat2
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) {
this.CurrentState = currentState;
//切换状态
this.CurrentState.setContext(this);
}/
/行为委托
public void handle1(){
this.CurrentState.handle1();
}p
ublic void handle2(){
this.CurrentState.handle2();
}
}
环境角色有两个不成文的约束:
● 把状态对象声明为静态常量, 有几个状态对象就声明几个静态常量。
● 环境角色具有状态抽象角色定义的所有行为, 具体执行使用委托方式。
我们再来看场景类如何执行, 如代码清单26-17所示。
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个。