状态模式是一种行为设计模式，允许一个对象在其内部状态改变时改变它的行为，使其看起来修改了自身所属的类。其别名为状态对象(Objects for States)。
State is a behavior design pattern that allows an object to change its behavior when its internal state changes,
making it appear to have modified the class it belongs to.
在很多情况下，一个对象的行为取决于一个或多个动态变化的属性，这样的属性叫做状态，这样的对象叫做有状态的(stateful)对象，这样的对象状态是从事先定义好的一系列值中取出的。
当一个这样的对象与外部事件产生互动时，其内部状态就会改变，从而使得系统的行为也随之发生变化。
在UML中可以使用状态图来描述对象状态的变化。
结构设计
Context，上下文类，保存了对于一个Concrete State对象(具体状态对象)的引用，并会将所有与该状态相关的工作委派给它。上下文通过状态接口与状态对象交互。
State，状态基类，接口会声明特定于状态的方法。
Concrete State，具体状态类，会自行实现特定于状态的方法。当多个状态中包含相似代码，可以提供一个封装有部分通用行为的中间抽象类。
状态对象可存储对于上下文对象的反向引用。状态对象可以通过该引用从上下文处获取所需信息，并且能触发状态转移。但这可能会带来对象的循环引用，在实际使用时，要通过对象传参的方式使用。
状态模式类图表示如下：
状态模式可能看上去与策略模式相似，但有一个关键性的不同——在状态模式中，特定状态知道其他所有状态的存在，且能触发从一个状态到另一个状态的转换，而策略则几乎完全不知道其他策略的存在。
伪代码实现
接下来将使用代码介绍下状态模式的实现。
// 1、State，状态接口，声明特定于状态的方法
public interface IState {
void handle(StateContext context);
void doSomething();
}
// 2、具体状态类，会自行实现特定于状态的方法，这里特定状态知道其他所有状态的存在，且能触发从一个状态到另一个状态的转换
public class ConcreteStateA implements IState {
private static ConcreteStateA state;
// 这里的单例实现暂不考虑并发场景
public static IState getInstance() {
if (state == null) {
state = new ConcreteStateA();
}
return state;
}
@Override
public void handle(StateContext context) {
doSomething();
context.setCurrentState(ConcreteStateB.getInstance());
}
@Override
public void doSomething() {
System.out.println("do some thing in the concrete A instance");
}
}
public class ConcreteStateB implements IState {
private static ConcreteStateB state;
// 这里的单例实现暂不考虑并发场景
public static IState getInstance() {
if (state == null) {
state = new ConcreteStateB();
}
return state;
}
@Override
public void handle(StateContext context) {
doSomething();
context.setCurrentState(ConcreteStateA.getInstance());
}
@Override
public void doSomething() {
System.out.println("do some thing in the concrete B instance");
}
}
// 3、状态上下文类，保存了对于一个Concrete State对象(具体状态对象)的引用，并会将所有与该状态相关的工作委派给它。
// 上下文通过状态接口与状态对象交互。
public class StateContext {
private IState currentState;
public StateContext(IState defaultState) {
this.currentState = defaultState;
}
public IState getCurrentState() {
return this.currentState;
}
public void setCurrentState(IState newState) {
this.currentState = newState;
}
public void request() {
currentState.handle(this);
}
}
// 4、客户端
public class StateClient {
public void test() {
StateContext stateContext = new StateContext(new ConcreteStateA());
stateContext.request();
stateContext.request();
stateContext.request();
}
}
适用场景
在以下情况下可以考虑使用状态模式：
(1) 对象的行为依赖于它的状态(属性)并且可以根据它的状态改变而改变它的相关行为，同时状态的数量非常多且与状态相关的代码会频繁变更的话，可以考虑使用状态模式。
(2) 代码中包含大量与对象状态有关的条件语句，这些条件语句的出现，会导致代码的可维护性和灵活性变差，不能方便地增加和删除状态，
使客户类与类库之间的耦合增强。在这些条件语句中包含了对象的行为，而且这些条件对应于对象的各种状态。
(3) 当相似状态和基于条件的状态机转换中存在许多重复代码时，可考虑使用状态模式。状态模式能够生成状态类层次结构，通过将公用代码抽取到抽象基类中来减少重复。
优缺点
状态模式有以下优点：
(1) 封装了转换规则。调用方无需关心状态转换的实现。
(2) 符合开闭原则。无需修改已有状态类和上下文就能引入新状态。
(3) 符合单一职责原则。将与特定状态相关的代码放在单独的类中。
(4) 消除了可能存在的条件语句。通过消除臃肿的状态机条件语句简化上下文代码。
(5) 可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
但是该模式也存在以下缺点：
(1) 如果状态机只有很少的几个状态， 或者很少发生改变， 那么应用该模式可能会显得小题大作。
(2) 增加系统类和对象的个数。
(3) 实现较为复杂，如果使用不当将导致程序结构和代码的混乱。
(4) 对“开闭原则”的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态；而且修改某个状态类的行为也需修改对应类的源代码。文章来源：https://www.toymoban.com/news/detail-634498.html
参考
《设计模式 可复用面向对象软件的基础》 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides 著, 李英军, 马晓星等译
https://design-patterns.readthedocs.io/zh_CN/latest/behavioral_patterns/state.html 状态模式
https://refactoringguru.cn/design-patterns/state 状态模式
https://www.runoob.com/design-pattern/state-pattern.html 状态模式
https://www.cnblogs.com/adamjwh/p/10926952.html 简说设计模式——状态模式文章来源地址https://www.toymoban.com/news/detail-634498.html
到了这里，关于状态模式(State)的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
