《Head-First-设计模式》笔记14-状态模式
定义
状态模式(State Pattern) :允许一个对象在其内部状态改变时改变它的行为,对象看起来似乎修改了它的类。其别名为状态对象(Objects for States),状态模式是一种对象行为型模式。
在很多情况下,一个对象的行为取决于一个或多个动态变化的属性,这样的属性叫做状态,这样的对象叫做有状态的(stateful)对象,这样的对象状态是从事先定义好的一系列值中取出的。当一个这样的对象与外部事件产生互动时,其内部状态就会改变,从而使得系统的行为也随之发生变化。
在有些情况下多个环境对象需要共享同一个状态,如果希望在系统中实现多个环境对象实例共享一个或多个状态对象,那么需要将这些状态对象定义为环境的静态成员对象。
类图
- Context: 环境类
- State: 抽象状态类
- ConcreteState: 具体状态类
State 抽象状态类
这里使用了接口,如果有共同的功能可以使用抽象类。
public interface State {
/**
* 状态对应的处理
*/
public void handle(String sampleParameter);
}
Context 环境类
public class Context {
private State stateA; // 所有状态
private State stateB;
// 持有一个 State 类型的对象实例,当前状态
private State state;
public Context() {
stateA = new ConcreteStateA(this);
stateB = new ConcreteStateB(this);
state = stateA;
}
public void setState(State state) {
this.state = state;
}
/**
* 用户感兴趣的接口方法
*/
public void request(String sampleParameter) {
// 转调state来处理
state.handle(sampleParameter);
}
public State getStateA() {
return stateA;
}
public State getStateB() {
return stateB;
}
}
第一个状态
public class ConcreteStateA implements State {
Context context;
public ConcreteStateA(Context context) {
this.context = context;
}
@Override
public void handle(String sampleParameter) {
System.out.println("具体状态A 处理 :" + sampleParameter);
context.setState(context.getStateB()); // 完成操作后,切换状态
}
}
第二个状态
public class ConcreteStateB implements State {
Context context;
public ConcreteStateB(Context context) {
this.context = context;
}
@Override
public void handle(String sampleParameter) {
System.out.println("具体状态B 处理 :" + sampleParameter);
context.setState(context.getStateA()); // 完成操作后,切换状态
}
}
测试
public class Client {
public static void main(String[] args){
Context context = new Context();
context.request("测试参数");
context.request("测试参数");
context.request("测试参数");
}
}/*output:
具体状态A 处理 :测试参数
具体状态B 处理 :测试参数
具体状态A 处理 :测试参数
*/
状态模式和策略模式的区别
状态模式:我们将一群行为封装在状态对象中,context 的行为随时可委托到那些状态对象中的一个。随着时间的流失,当前状态在状态对象集合中游走改变,以反映出 context 内部的状态,因此,context 的行为也会跟着改变;
策略模式:客户通常主动指定 Context 所要组合的策略对象是哪一个。现在,固然策略模式让我们具有弹性,能够在运行时改变策略。但对于某个 context 对象来说,通常都只有一个 最适当的策略对象。
一般而言,我们把策略模式想成是除了继承外的一种弹性替代方案。如果你使用继承定义了一个类的行为,你将被这个行为所困住,甚至要修改他都很难。有了策略模式,你可以通过组合不同对象来改变行为;
我们把状态模式想成是不用在 context 中放置许多条件判断的替代方案。通过将行为包装进状态对象中,你可以通过 context 内简单地修改状态对象来改变 context 的行为;
优点
- 封装了转换规则。
- 枚举可能的状态,在枚举状态之前需要确定状态种类。
- 将所有与某个状态有关的行为放到一个类中,并且可以方便地增加新的状态,只需要改变对象状态即可改变对象的行为。
- 允许状态转换逻辑与状态对象合成一体,而不是某一个巨大的条件语句块。
- 可以让多个环境对象共享一个状态对象,从而减少系统中对象的个数。
缺点
- 状态模式的使用必然会增加系统类和对象的个数。
- 状态模式的结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱。
- 状态模式对“开闭原则”的支持并不太好,对于可以切换状态的状态模式,增加新的状态类需要修改那些负责状态转换的源代码,否则无法切换到新增状态;而且修改某个状态类的行为也需修改对应类的源代码。
适用环境
- 对象的行为依赖于它的状态(属性)并且可以根据它的状态改变而改变它的相关行为。
- 代码中包含大量与对象状态有关的条件语句,这些条件语句的出现,会导致代码的可维护性和灵活性变差,不能方便地增加和删除状态,使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为,而且这些条件对应于对象的各种状态。
转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 bin07280@qq.com
文章标题:《Head-First-设计模式》笔记14-状态模式
文章字数:1.3k
本文作者:Bin
发布时间:2018-07-15, 14:42:43
最后更新:2019-08-06, 00:07:35
原始链接:http://coolview.github.io/2018/07/15/Head-First-%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/%E3%80%8AHead-First-%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E3%80%8B%E7%AC%94%E8%AE%B014-%E7%8A%B6%E6%80%81%E6%A8%A1%E5%BC%8F/版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。