行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式:
-
类行为模式:采用继承机制来在类间分派行为
-
对象行为模式:采用组合或聚合在对象间分配行为
由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。
行为型模式分为:
- 模板方法模式
- 策略模式
- 命令模式
- 职责链模式
- 状态模式
- 观察者模式
- 中介者模式
- 迭代器模式
- 访问者模式
- 备忘录模式
- 解释器模式
以上 11 种行为型模式,除了模板方法模式和解释器模式是类行为型模式,其他的全部属于对象行为型模式。
状态模式
**状态模式:**对有状态的对象,把复杂的 “判断逻辑” 提取到不同的状态对象中,允许状态对象在其内部状态发生改变时改变其行为
(对象似乎看起来修改了它的类)
- 在状态模式(State Pattern)中,类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。
- 允许对象在内部状态发生改变时改变它的行为,对象看起来好像修改了它的类。
解决的问题
反例
通过按钮来控制一个电梯的状态,一个电梯有开门状态,关门状态,停止状态,运行状态。每一种状态改变,都有可能要根据其他状态来更新处理。例如,如果电梯门现在处于运行时状态,就不能进行开门操作,而如果电梯门是停止状态,就可以执行开门操作。类图如下:
电梯接口
public interface ILift {
//定义四个电梯状态的常量
int OPENING_STATE = 1;
int CLOSING_STATE = 2;
int RUNNING_STATE = 3;
int STOPPING_STATE = 4;
//设置电梯状态的功能
void setState(int state);
//电梯的操作功能
void open();
void close();
void run();
void stop();
}
电梯实现
public class Lift implements ILift{
// 声明一个记录当前电梯的状态
private int state;
@Override
public void setState(int state) {
this.state = state;
}
@Override
public void open() {
switch (state){
case OPENING_STATE:
//什么事也不做
break;
case CLOSING_STATE:
System.out.println("电梯打开了...");
//设置当前电梯状态为开启状态
setState(OPENING_STATE);
break;
case STOPPING_STATE:
System.out.println("电梯打开了...");
//设置当前电梯状态为开启状态
setState(OPENING_STATE);
break;
case RUNNING_STATE:
//什么事都不做
break;
}
}
@Override
public void close() {
switch (this.state) {
case OPENING_STATE:
System.out.println("电梯关门了。。。");//只有开门状态可以关闭电梯门,可以对应电梯状态表来看
this.setState(CLOSING_STATE);//关门之后电梯就是关闭状态了
break;
case CLOSING_STATE:
//do nothing //已经是关门状态,不能关门
break;
case RUNNING_STATE:
//do nothing //运行时电梯门是关着的,不能关门
break;
case STOPPING_STATE:
//do nothing //停止时电梯也是关着的,不能关门
break;
}
}
@Override
public void run() {
switch (this.state) {
case OPENING_STATE://电梯不能开着门就走
//do nothing
break;
case CLOSING_STATE://门关了,可以运行了
System.out.println("电梯开始运行了。。。");
this.setState(RUNNING_STATE);//现在是运行状态
break;
case RUNNING_STATE:
//do nothing 已经是运行状态了
break;
case STOPPING_STATE:
System.out.println("电梯开始运行了。。。");
this.setState(RUNNING_STATE);
break;
}
}
@Override
public void stop() {
switch (this.state) {
case OPENING_STATE: //开门的电梯已经是是停止的了(正常情况下)
//do nothing
break;
case CLOSING_STATE://关门时才可以停止
System.out.println("电梯停止了。。。");
this.setState(STOPPING_STATE);
break;
case RUNNING_STATE://运行时当然可以停止了
System.out.println("电梯停止了。。。");
this.setState(STOPPING_STATE);
break;
case STOPPING_STATE:
//do nothing
break;
}
}
}
问题分析:
- 使用了大量的 switch…case 这样的判断(if…else也是一样),使程序的可阅读性变差。
- 扩展性很差。如果新加了断电的状态,我们需要修改上面判断逻辑
结构
- 环境(Context)角色:也称为上下文,它定义了客户程序需要的接口,维护一个当前状态,并将与状态相关的操作委托给当前状态对象来处理。
- 抽象状态(State)角色:定义一个接口,用以封装环境对象中的特定状态所对应的行为。每个状态通过持有Context的引用,来实现状态转移
- 具体状态(Concrete State)角色:实现抽象状态所对应的行为。
实例
抽象状态类:
public abstract class LiftState {
// 声明环境角色类变量
protected Context context;
public void setContext(Context context) {
this.context = context;
}
// 电梯开启操作
public abstract void open();
// 电梯关闭操作
public abstract void close();
// 电梯运行操作
public abstract void run();
// 电梯停止操作
public abstract void stop();
}
具体状态类:电梯开门状态、电梯运行状态 、电梯停止状态、电梯关门状态
public class OpeningState extends LiftState {
// 当前状态要执行的方法
public void open() {
System.out.println("电梯开启。。。");
}
public void close() {
// 修改状态
super.context.setLiftState(Context.CLOSING_STATE);
// 修改环境
super.context.close();
}
public void run() {}
public void stop() {}
}
public class ClosingState extends LiftState {
// 当前状态要执行的方法
public void close() {
System.out.println("电梯门关闭...");
}
// 关闭 -> 开启
public void open() {
super.context.setLiftState(Context.OPENING_STATE);
super.context.open();
}
// 关闭 -> 运行
public void run() {
super.context.setLiftState(Context.RUNNING_STATE);
super.context.run();
}
// 关闭 -> 停止
public void stop() {
super.context.setLiftState(Context.STOPPING_STATE);
super.context.stop();
}
}
public class RunningState extends LiftState{
@Override
// 运行时无法开门
public void open() {
}
@Override
// 运行时门是关的
public void close() {
}
@Override
// 当前状态要执行的方法
public void run() {
System.out.println("电梯正在运行...");
}
@Override
// 运行 -> 停止
public void stop() {
super.context.setLiftState(Context.STOPPING_STATE);
super.context.stop();
}
}
public class StoppingState extends LiftState{
@Override
// 停止 -> 开门(委托给ClosingState子类执行)
public void open() {
super.context.setLiftState(Context.OPENING_STATE);
super.context.getLiftState().open();
}
@Override
// 停止 -> 关门(委托给OpeningState子类执行)
public void close() {
super.context.setLiftState(Context.CLOSING_STATE);
super.context.getLiftState().close();
}
@Override
// 停止 -> 运行(委托给 RunningState子类执行)
public void run() {
super.context.setLiftState(Context.RUNNING_STATE);
super.context.getLiftState().run();
}
@Override
// 当前状态要执行的方法
public void stop() {
System.out.println("电梯停止了...");
}
}
环境角色类:
public class Context {
// 定义对应状态对象的常量
public final static OpeningState OPENING_STATE = new OpeningState();
public final static ClosingState CLOSING_STATE = new ClosingState();
public final static RunningState RUNNING_STATE = new RunningState();
public final static StoppingState STOPPING_STATE = new StoppingState();
// 定义一个当前电梯状态变量
private LiftState liftState;
public LiftState getLiftState() {
return liftState;
}
// 设置当前状态对象
public void setLiftState(LiftState liftState) {
this.liftState = liftState;
// 设置当前状态对象中的Context对象
this.liftState.setContext(this);
}
public void open() {
this.liftState.open();
}
public void close() {
this.liftState.close();
}
public void run() {
this.liftState.run();
}
public void stop() {
this.liftState.stop();
}
}
测试
public class Client {
public static void main(String[] args) {
// 创建环境角色对象
Context context = new Context();
// 设置当前电梯装填
context.setLiftState(new ClosingState());
context.open();
context.run();
context.close();
context.stop();
}
}
存在的问题
优点:
-
将所有与某个状态有关的行为放到一个类中,并且可以方便地增加新的状态,只需要改变对象状态即可改变对象的行为。
-
允许状态转换逻辑与状态对象合成一体,而不是某一个巨大的条件语句块。
缺点:
- 状态模式的使用必然会增加系统类和对象的个数。
- 状态模式的结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱。
- 状态模式对 “开闭原则” 的支持并不太好。
使用场景
- 当一个对象的行为取决于它的状态,并且它必须在运行时根据状态改变它的行为时,就可以考虑使用状态模式。
- 一个操作中含有庞大的分支结构,并且这些分支决定于对象的状态时。
状态模式与策略模式的区别
-
状态强调的状态的不同,状态不同,要做的事情不同(开心->买肯德基犒劳犒劳自己,不开心->明天请假不上班),聚焦在开心或者不开心上,而开心或者不开心,具体要做什么不关心,你不开心明天辞职也可以
- 状态模式是根据状态来决定行为,不同状态之下会采取一系列不同的行为(所有的方法的实现都可能发生变化)
- 状态模式帮助一个类在不同的状态显示不同的行为。
- 比如,在状态模式下,如果我今天的状态是“不开心”,那么我起床、吃饭、读书、睡觉等一系列行为都会受到影响
- 状态模式是根据状态来决定行为,不同状态之下会采取一系列不同的行为(所有的方法的实现都可能发生变化)
-
策略模式仅关注某一个行为的具体执行过程,比如我读书怎么读?站着坐着还是躺着?强调的是“做的步骤”,即行为、算法本身
- 但策略模式没有状态的概念,它直接关注于行为的实现方案(某一个行为的具体执行过程),更多地关注的是项目中变化与不变的部分。
- 策略模式封装了一组相关算法,它允许Client在运行时使用可互换的行为
-
策略实现可以作为参数传递给使用它的对象,例如Collections.sort(),它的参数包含一个Comparator策略。另一方面,状态是Context对象自己的一部分,随着时间的推移,Context对象从一个状态转移到另一个状态。
-
在状态模式中,每个状态通过持有Context的引用,来实现状态转移;但是每个策略都不持有Context的引用,它们只是被Context使用。
- 状态模式中很好的定义了状态转移的次序;而策略模式并无此需要:Client可以自由的选择任何策略。
-
最后但最重要的一个不同之处是,策略的改变由Client完成;而状态的改变,由Context或状态自己。
-
一些常见的策略模式的例子是封装算法,例如排序算法,加密算法或者压缩算法。如果你看到你的代码需要使用不同类型的相关算法,那么考虑使用策略模式吧。而识别何时使用状态模式是很简单的:如果你需要管理状态和状态转移,但不想使用大量嵌套的条件语句,那么就是它了。
状态还涉及到状态切换的过程,这个过程是可以由状态内部决定的,不需要外界干涉,这一点就和策略模式不一样了,策略主要变化因素受外界影响的。
超过三层的if-else语句的逻辑判断代码可以使用卫语句,策略模式,状态模式
public void today(){
if(isBusy()){
System.out.println("no time")
}
}
- 卫语句就是提前结束方法