状态模式

电梯具有的动作：

• 开门：乘客进入、出去。
• 关门：电梯准备开始运行。
• 运行：上下运行。
• 停止：停止运行。

1、先让电梯运行起来

image.png

//定义电梯接口
public interface ILift {
    void open();
    void close();
    void run();
    void stop();
}
//电梯实现类
public class LiftImp implements ILift{
    @Override
    public void open() {
        System.out.println("电梯开门了……");
    }

    @Override
    public void close() {
        System.out.println("电梯关门了……");
    }

    @Override
    public void run() {
        System.out.println("电梯运行起来了……");
    }

    @Override
    public void stop() {
        System.out.println("电梯停止了……");
    }
}

思考：这个程序有什么问题？

电梯门可以打开，但不是随时都可以开，是有前提条件的。你不可能电梯在运行的时候突然开门吧？！电梯也不会出现停止了但是不开门的情况吧？！那要是有也是事故。再仔细想想，电梯的这4个动作的执行都有前置条件，具体点说就是在特定状态下才能做特定事，那我们来分析一下电梯有哪些特定状态。

• 敞门状态：按了电梯上下按钮，电梯门开，这中间大概有10秒的时间，那就是敞门状态。在这个状态下电梯只能做的动作是关门动作。
• 闭门状态：电梯门关闭了，在这个状态下，可以进行的动作是：开门（我不想坐电梯了）、停止（忘记按路层号了）、运行。
• 运行状态：电梯正在跑，上下窜，在这个状态下，电梯只能做的是停止。
• 停止状态：电梯停止不动，在这个状态下，电梯有两个可选动作：继续运行和开门动作。

我们用一张表来表示电梯状态和动作之间的关系：

image.png

2、修复一下电梯的异常

image.png

//接口中增加了状态
public interface ILift2 {
    public final static int OPENING_STATE = 1;  //敞门状态
    public final static int CLOSING_STATE = 2;  //闭门状态
    public final static int RUNNING_STATE = 3;  //运行状态
    public final static int STOPPING_STATE = 4; //停止状态
    void open();
    void close();
    void run();
    void stop();
}
public class LiftImp2 implements ILift2 {

    private int state;

    public void setState(int state) {
        this.state = state;
    }
    @Override
    public void open() {
        //电梯在什么状态才能开启
        switch (this.state) {
            case OPENING_STATE: //闭门状态，什么都不做
                //do nothing;
                break;
            case CLOSING_STATE: //闭门状态，则可以开启
                System.out.println("电梯开门了……");
                this.setState(OPENING_STATE);
                break;
            case RUNNING_STATE: //运行状态，则不能开门，什么都不做
                //do nothing;
                break;
            case STOPPING_STATE: //停止状态，当然要开门了
                System.out.println("电梯开门了……");
                this.setState(OPENING_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);
        }

    }
    @Override
    public void stop() {
        switch (this.state) {
            case OPENING_STATE: //敞门状态，要先停下来的，什么都不做
                //do nothing;
                break;
            case CLOSING_STATE: //闭门状态，则当然可以停止了
                System.out.println("电梯停止了……");
                this.setState(CLOSING_STATE);
                break;
            case RUNNING_STATE: //运行状态，有运行当然那也就有停止了
                System.out.println("电梯停止了……");
                this.setState(CLOSING_STATE);
                break;
            case STOPPING_STATE: //停止状态，什么都不做
                //do nothing;
                break;
        }
    }
}

思考：这个程序有什么问题？

• 电梯实现类Lift有点长

  长的原因是我们在程序中使用了大量的switch...case这样的判断（if...else也是一样），程序中只要有这样的判断就避免不了加长程序，而且在业务复杂的情况下，程序会更长，这就不是一个很好的习惯了，较长的方法和类无法带来良好的维护性，毕竟，程序首先是给人阅读的，然后才是机器执行。

• 扩展性非常差劲

  大家来想想，电梯还有两个状态没有加，是什么？通电状态和断电状态，你要是在程序增加这两个方法，你看看Open()、Close()、Run()、Stop()这4个方法都要增加判断条件，也就是说switch判断体中还要增加case项，这与开闭原则相违背。

• 非常规状态无法实现

  我们来思考我们的业务，电梯在门敞开状态下就不能上下运行了吗？电梯有没有发生过只有运行没有停止状态呢（从40层直接坠到1层嘛）？电梯故障嘛，还有电梯在检修的时候，可以在stop状态下不开门，这也是正常的业务需求呀，你想想看，如果加上这些判断条件，上面的程序有多少需要修改？虽然这些都是电梯的业务逻辑，但是一个类有且仅有一个原因引起类的变化，单一职责原则，看看我们的类，业务任务上一个小小的增加或改动都使得我们这个电梯类产生了修改，这在项目开发上是有很大风险的。

如何解决这些问题？刚刚我们都是从电梯的执行方法来分析的，换一个角度：状态！可以将电梯的运行抽解成两个任务模型：

• 当前状态如何来的？比如停止状态，肯定是执行了stop方法来的。
• 在当前状态下能执行哪些动作？比如停止状态下，能执行开门、运行。

3、让电梯完美的运行起来

image.png

在类图中，定义了一个LiftState抽象类，声明了一个受保护的类型Context变量，这个是串联各个状态的封装类。封装的目的很明显，就是电梯对象内部状态的变化不被调用类知晓，也就是迪米特法则了（我的类内部情节你知道得越少越好），并且还定义了4个具体的实现类，承担的是状态的产生以及状态间的转换过渡，每个实现类都有open、close、run、stop四个方法。

对于context我们可以这样理解：Context是一个环境角色，它的作用是串联各个状态的过渡，在LiftSate抽象类中我们定义并把这个环境角色聚合进来，并传递到子类，也就是4个具体的实现类中自己根据环境来决定如何进行状态的过渡。

对于LiftState实现类中的方法，以OpenningState为例进行解释：Openning状态是由open()方法产生的，因此，在这个方法中有一个具体的业务逻辑，我们是用print来代替了。在Openning状态下，电梯能过渡到其他什么状态呢？按照现在的定义的是只能过渡到Closing状态，因此我们在Close()中定义了状态变更，同时把Close这个动作也委托了给CloseState类下的Close方法执行，

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 Context {
    //定义出所有的电梯状态
    public final static OpenningState openningState = new OpenningState();
    public final static ClosingState closeingState = new ClosingState();
    public final static RunningState runningState = new RunningState();
    public final static StoppingState stoppingState = new StoppingState();
    //定义一个当前电梯状态
    private LiftState liftState;
    public LiftState getLiftState() {
        return liftState;
    }
    public void setLiftState(LiftState liftState) {
        this.liftState = liftState;
        //把当前的环境通知到各个实现类中
        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 OpenningState extends LiftState {
     //开启当然可以关闭了，我就想测试一下电梯门开关功能
     @Override
     public void close() {
             //状态修改
             super.context.setLiftState(Context.closeingState);
             //动作委托为CloseState来执行
             super.context.getLiftState().close();
     }
     //打开电梯门
     @Override
     public void open() {
             System.out.println("电梯门开启...");
     }
     //门开着时电梯就运行跑，这电梯，吓死你！
     @Override
     public void run() {
             //do nothing;
     }
     //开门还不停止？
     public void stop() {
             //do nothing;
     }
}
public class ClosingState extends LiftState{
    //电梯门关闭，这是关闭状态要实现的动作
    @Override
    public void close() {
        System.out.println("电梯门关闭...");
    }
    //电梯门关了再打开
    @Override
    public void open() {
        super.context.setLiftState(Context.openningState);  //置为敞门状态
        super.context.getLiftState().open();
    }
    //电梯门关了就运行，这是再正常不过了
    @Override
    public void run() {
        super.context.setLiftState(Context.runningState); //设置为运行状态
        super.context.getLiftState().run();
    }
    //电梯门关着，我就不按楼层
    @Override
    public void stop() {
        super.context.setLiftState(Context.stoppingState);  //设置为停止状态
        super.context.getLiftState().stop();
    }
}
public class RunningState extends LiftState {
    //电梯门关闭？这是肯定的
    @Override
    public void close() {
        //do nothing
    }
    //运行的时候开电梯门？你疯了！电梯不会给你开的
    @Override
    public void open() {
        //do nothing
    }
    //这是在运行状态下要实现的方法
    @Override
    public void run() {
        System.out.println("电梯上下运行...");
    }
    //这绝对是合理的，只运行不停止还有谁敢坐这个电梯？！估计只有上帝了
    @Override
    public void stop() {
        super.context.setLiftState(Context.stoppingState);//环境设置为停止状态
        super.context.getLiftState().stop();
    }
}
public class StoppingState extends LiftState {
    //停止状态关门？电梯门本来就是关着的！
    @Override
    public void close() {
        //do nothing;
    }
    //停止状态，开门，那是要的！
    @Override
    public void open() {
        super.context.setLiftState(Context.openningState);
        super.context.getLiftState().open();
    }
    //停止状态再运行起来，正常得很
    @Override
    public void run() {
        super.context.setLiftState(Context.runningState);
        super.context.getLiftState().run();
    }
    //停止状态是怎么发生的呢？当然是停止方法执行了
    @Override
    public void stop() {
        System.out.println("电梯停止了...");
    }
}

总结一下：

代码太长的问题：通过各个子类来实现，每个子类的代码都很短，而且也取消了switch...case条件的判断。

不符合开闭原则：如果在我们这个例子中要增加两个状态应该怎么做呢？增加两个子类，一个是通电状态，另一个是断电状态，同时修改其他实现类的相应方法，因为状态要过渡，那当然要修改原有的类，只是在原有类中的方法上增加，而不去做修改。

不符合迪米特法则：我们现在的各个状态是单独的类，只有与这个状态有关的因素修改了，这个类才修改，符合迪米特法则。

非常完美!这就是状态模式。

4、总结

1、状态模式的定义：

当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。（Allow an object to alter its behavior when its internal state changes.The object will appear to change its class.）

状态模式的核心是封装，状态的变更引起了行为的变更，从外部看起来就好像这个对象对应的类发生了改变一样。

2、状态模式中的3个角色：

• State——抽象状态角色：接口或抽象类，负责对象状态定义，并且封装环境角色以实现状态切换。
• ConcreteState——具体状态角色：每一个具体状态必须完成两个职责：本状态的行为管理以及趋向状态处理，通俗地说，就是本状态下要做的事情，以及本状态如何过渡到其他状态。
• Context——环境角色：定义客户端需要的接口，并且负责具体状态的切换。

3、状态模式的优点

• 结构清晰：避免了过多的switch...case或者if...else语句的使用，避免了程序的复杂性,提高系统的可维护性。
• 遵循设计原则：很好地体现了开闭原则和单一职责原则，每个状态都是一个子类，你要增加状态就要增加子类，你要修改状态，你只修改一个子类就可以了。
• 封装性非常好：这也是状态模式的基本要求，状态变换放置到类的内部来实现，外部的调用不用知道类内部如何实现状态和行为的变换。

4、状态模式的缺点

子类会太多，也就是类膨胀。如果一个事物有很多个状态也不稀奇，如果完全使用状态模式就会有太多的子类，不好管理，这个需要大家在项目中自己衡量。

5、状态模式的使用场景

• 行为随状态改变而改变的场景
  这也是状态模式的根本出发点，例如权限设计，人员的状态不同即使执行相同的行为结果也会不同，在这种情况下需要考虑使用状态模式。

• 条件、分支判断语句的替代者
  在程序中大量使用switch语句或者if判断语句会导致程序结构不清晰，逻辑混乱，使用状态模式可以很好地避免这一问题，它通过扩展子类实现了条件的判断处理。

参考书籍《设计模式之禅》：https://www.kancloud.cn/sstd521/design/193608