状态模式
简介
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.
允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
在软件开发过程中，对于某一项操作，可能存在不同的情况。通常处理多情况问题最直接的方式就是使用if...else或switch...case条件语句进行枚举。但是这种做法对于复杂状态的判断天然存在弊端：条件判断语句过于臃肿，可读性差，且不具备扩展性，维护难度也大。而如果转换思维，将这些不同状态独立起来用各个不同的类进行表示，系统处于哪种情况，直接使用相应的状态类对象进行处理，消除了if...else，switch...case等冗余语句，代码更有层次性且具备良好扩展力。
状态模式（State Pattern）主要解决的就是当控制一个对象状态的条件表达式过于复杂时的情况。通过把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。
状态模式 中类的行为是由状态决定的，不同的状态下有不同的行为。其意图是让一个对象在其内部改变的时候，其行为也随之改变。
状态模式 核心：状态与行为绑定，不同的状态对应不同的行为。
主要解决
对象的行为依赖于它的状态（属性），并且会根据它的状态改变而改变它的相关行为。
优缺点
优点
- 结构清晰：将状态独立为类，消除了冗余的
if...else或switch...case语句，使代码更加简洁，提高系统可维护性； - 将状态转换显示化：通常的对象内部都是使用数值类型来定义状态，状态的切换是通过赋值进行表现，不够直观；而使用状态类，在切换状态时，是以不同的类进行表示，转换目的更加明确；
- 状态类职责明确且具备扩展性；
缺点
- 类膨胀：如果一个事物具备很多状态，则会造成状态类太多；
- 状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱；
- 状态模式对 开闭原则 的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码；
使用场景
- 行为随状态改变而改变的场景；
- 一个操作中含有庞大的多分支结构，并且这些分支取决于对象的状态；
模式讲解
首先来看下 状态模式 的通用 UML 类图：
状态模式
从 UML 类图中，我们可以看到，状态模式 主要包含三种角色：
- 环境类角色（Context）：定义客户端需要的接口，内部维护一个当前状态实例，并负责具体状态的切换；
- 抽象状态角色（State）：定义该状态下的行为，可以有一个或多个行为；
- 具体状态角色（ConcreteState）：具体实现该状态对应的行为，并且在需要的情况下进行状态切换；
以下是 状态模式 的通用代码：
class Client {
public static void main(String[] args) {
Context context = new Context();
context.setState(new ConcreteStateB());
context.handle();
}
//抽象状态：State
interface IState {
void handle();
}
//具体状态类
static class ConcreteStateA implements IState {
@Override
public void handle() {
//必要时刻需要进行状态切换
System.out.println("StateA do action");
}
}
//具体状态类
static class ConcreteStateB implements IState {
@Override
public void handle() {
//必要时刻需要进行状态切换
System.out.println("StateB do action");
}
}
//环境类
static class Context {
private static final IState STATE_A = new ConcreteStateA();
private static final IState STATE_B = new ConcreteStateB();
//默认状态A
private IState mCurrentState = STATE_A;
public void setState(IState state) {
this.mCurrentState = state;
}
public void handle() {
this.mCurrentState.handle();
}
}
}
注：上面的代码很好地展现了 状态模式 状态分离的好处，代码清晰。不过上面的代码还未能完全展示 状态模式 的全貌，因为不同的状态之间可能存在自动切换的场景（比如手机处于开机状态后就会立即切换到屏幕点亮状态···），但是上面的代码未体现出切换场景功能。我们可以对上面的代码进行修改，使其满足状态切换功能。具体代码如下所示：
class Client {
public static void main(String[] args) {
Context context = new Context();
context.setState(new ConcreteStateA());
context.handle();
}
// 抽象状态：State
static abstract class State {
protected Context mContext;
public void setContext(Context context) {
this.mContext = context;
}
public abstract void handle();
}
// 具体状态类
static class ConcreteStateA extends State {
@Override
public void handle() {
System.out.println("StateA do action");
// A状态完成后自动切换到B状态
this.mContext.setState(Context.STATE_B);
this.mContext.getState().handle();
}
}
...
...
// 环境类
static class Context {
public static final State STATE_A = new ConcreteStateA();
public static final State STATE_B = new ConcreteStateB();
// 默认状态A
private State mCurrentState = STATE_A;
{
STATE_A.setContext(this);
STATE_B.setContext(this);
}
public void setState(State state) {
this.mCurrentState = state;
this.mCurrentState.setContext(this);
}
public State getState() {
return this.mCurrentState;
}
public void handle() {
this.mCurrentState.handle();
}
}
}
主要就是将抽象状态类State由接口改成抽象类，增加对环境类Context的维护，让具体状态ConcreteState可以不必耦合其他具体状态类，而是借由Context间接进行切换功能。
上面的代码中，客户端访问的是 A 状态，但是程序运行后会自动切换到 B 状态。运行结果如下：
StateA do action
StateB do action
举个例子
例子：比如在简书App阅读文章时，觉得文章写的很好，评论收藏两连发。但是如果处于未登录状态，则要先进行登陆，然后再会执行前面的操作。请用代码实现上述逻辑。
分析：上述的例子很简单，就是一个登陆问题：处于登陆情况下，我们就可以做评论，收藏这些行为，否则，跳转到登陆界面，登陆后再继续执行先前的动作。这里涉及的状态有两种：登陆与未登录，行为有两种：评论，收藏。下面我们使用 状态模式 进行实现，代码如下：
class Client {
public static void main(String[] args) {
AppContext context = new AppContext();
context.favorite();
context.comment("comment: good article.I like it!");
}
static class AppContext {
public static final UserState STATE_LOGIN_IN = new LoginInState();
public static final UserState STATE_LOGIN_OUT = new LoginOutState();
private UserState mCurrentState = STATE_LOGIN_OUT;
{
STATE_LOGIN_IN.setContext(this);
STATE_LOGIN_OUT.setContext(this);
}
public void setState(UserState state) {
this.mCurrentState = state;
this.mCurrentState.setContext(this);
}
public UserState getState() {
return this.mCurrentState;
}
public void favorite() {
this.mCurrentState.favorite();
}
public void comment(String comment) {
this.mCurrentState.comment(comment);
}
}
static abstract class UserState {
protected AppContext mContext;
public void setContext(AppContext context) {
this.mContext = context;
}
public abstract void favorite();
public abstract void comment(String comment);
}
static class LoginInState extends UserState {
@Override
public void favorite() {
System.out.println("favorite: save it");
}
@Override
public void comment(String comment) {
System.out.println(comment);
}
}
static class LoginOutState extends UserState {
@Override
public void favorite() {
this.switch2Login();
this.mContext.getState().favorite();
}
@Override
public void comment(String comment) {
this.switch2Login();
this.mContext.getState().comment(comment);
}
private void switch2Login() {
System.out.println("jump to login interface!");
this.mContext.setState(this.mContext.STATE_LOGIN_IN);
}
}
}
结果如下：
jump to login interface!
favorite: save it
comment: good article.I like it!
与其他模式的比较
-
状态模式 vs 责任链模式
状态模式 和 责任链模式 都能消除if分支过多的问题。某些情况下， 状态模式 中的状态可以理解为责任，那么这种情况下，两种模式都可以使用。
从定义来看，状态模式 强调的是一个对象内在状态的改变，而 责任链模式 强调的是外部节点对象间的改变。
从其代码实现上来看，他们间最大的区别就是 状态模式 各个状态对象知道自己下一个要进入的状态对象；而 责任链模式 并不清楚其下一个节点处理对象，因为链式组装由客户端负责。 -
状态模式 vs 策略模式
状态模式 和 策略模式 的 UML 类图架构几乎完全一样，但他们的应用场景是不一样的。策略模式 多种算法行为择其一都能满足，彼此之间是独立的，用户可自行更换策略算法；而 状态模式 各个状态间是存在相互关系的，彼此之间在一定条件下存在自动切换状态效果，且用户无法指定状态，只能设置初始状态。
