第十三篇 : (State)状态模式
程序员文章站
2022-05-03 22:30:14
...
第十三篇:状态模式
定义
GoF为状态模式给出的定义是:允许一个对象在其内部状态发生变化时改变自己的行为,该对象看起来好像你改变他的类型。
UML静态类图
使用案例
有这样一个电子颜料版,他上面有个手柄,可以拉(pull)也可以推(push),每次操作,都会改变颜料的颜色,他们的变化关系如图所示
用传统的方式解决
这段代码并没有什么不妥,我们知道,需求总是不停变化的,如果又有新的状态需要加入时,这时就得在push()方法中添加新的case分支语句,这就破坏了OCP原则【OCP:一个好的设计应该能够容纳新的功能或者需求的添加,但是添加的方式不是通过改变现有的类(模块),而是通过添加新的类(模块)来完成的,也就是说,在设计的时候,所有软件组成的的实体包括接口、类、函数等...必须都是可以拓展的,但是拓展的方式不是通过修改现有的东西】,上面的颜色很少,如果业务逻辑复杂,一个case分支就会超过百行,代码就会变得很难阅读和维护。
采用状态模式进行解决
从上图可以看出,在不同的颜色下pash(推)和pull(拉)操作颜色变化都是不一样的,例如:当颜色为red时pull状态就变成Green,而Green的pull时状态就变成Blue,
根据上面的UML图我们为此我们抽象出一个状态接口State,它定义了与状态相关的方法。PaintBoard类包涵pull()、push()两个方法,它把这两个操作委托给当前状态完成。
PaintBoard类如下
State接口代码如下
RedState类代码如下
BuleState类代码如下
GreenState类代码如下
测试代码如下
这样,PaintBoard类的代码里就在也找不到条件分支语句啦,代码也更容易阅读。最重要的是如果以后要添加许多的状态,只要添加新的State接口的实现即可,符合OCP原则,我们知道软件维护是最麻烦的,在大型项目开发中,以后维护就变得相当的容易
定义
GoF为状态模式给出的定义是:允许一个对象在其内部状态发生变化时改变自己的行为,该对象看起来好像你改变他的类型。
UML静态类图
使用案例
有这样一个电子颜料版,他上面有个手柄,可以拉(pull)也可以推(push),每次操作,都会改变颜料的颜色,他们的变化关系如图所示
用传统的方式解决
public void push(ColorState state){ switch (state) { case RED: state=ColorState.GREEN; break; case GREEN: state=ColorState.BLUE; case BLUE: state=ColorState.RED; default: break; } }
这段代码并没有什么不妥,我们知道,需求总是不停变化的,如果又有新的状态需要加入时,这时就得在push()方法中添加新的case分支语句,这就破坏了OCP原则【OCP:一个好的设计应该能够容纳新的功能或者需求的添加,但是添加的方式不是通过改变现有的类(模块),而是通过添加新的类(模块)来完成的,也就是说,在设计的时候,所有软件组成的的实体包括接口、类、函数等...必须都是可以拓展的,但是拓展的方式不是通过修改现有的东西】,上面的颜色很少,如果业务逻辑复杂,一个case分支就会超过百行,代码就会变得很难阅读和维护。
采用状态模式进行解决
从上图可以看出,在不同的颜色下pash(推)和pull(拉)操作颜色变化都是不一样的,例如:当颜色为red时pull状态就变成Green,而Green的pull时状态就变成Blue,
根据上面的UML图我们为此我们抽象出一个状态接口State,它定义了与状态相关的方法。PaintBoard类包涵pull()、push()两个方法,它把这两个操作委托给当前状态完成。
PaintBoard类如下
public void push(ColorState state){ switch (state) { case RED: state=ColorState.GREEN; break; case GREEN: state=ColorState.BLUE; case BLUE: state=ColorState.RED; default: break; } }
State接口代码如下
public interface State { String getColor(); void push(PaintBoard paintBoard); void pull(PaintBoard paintBoard); }
RedState类代码如下
public class RedState implements State{ @Override public String getColor() { return "RED"; } @Override public void push(PaintBoard paintBoard) { paintBoard.setState(new GreenState()); } @Override public void pull(PaintBoard paintBoard) { paintBoard.setState(new BuleState()); } }
BuleState类代码如下
public class BuleState implements State { @Override public String getColor() { return "BULE"; } @Override public void push(PaintBoard paintBoard) { paintBoard.setState(new RedState()); } @Override public void pull(PaintBoard paintBoard) { paintBoard.setState(new GreenState()); } }
GreenState类代码如下
public class GreenState implements State { @Override public String getColor() { return "GREEN"; } @Override public void push(PaintBoard paintBoard) { paintBoard.setState(new BuleState()); } @Override public void pull(PaintBoard paintBoard) { paintBoard.setState(new RedState()); } }
测试代码如下
public class StateTest { public static void main(String[] args) { PaintBoard paintBoard=new PaintBoard(new RedState()); System.out.println(paintBoard.getColor()); paintBoard.push(); System.out.println(paintBoard.getColor()); paintBoard.push(); System.out.println(paintBoard.getColor()); } }
这样,PaintBoard类的代码里就在也找不到条件分支语句啦,代码也更容易阅读。最重要的是如果以后要添加许多的状态,只要添加新的State接口的实现即可,符合OCP原则,我们知道软件维护是最麻烦的,在大型项目开发中,以后维护就变得相当的容易