记一次代码重构--状态机编程

重构背景

最近在开发这样一个管理系统：将公司多台服务器上的查询SQL相关信息（用户，查询语句，查询类型，起始时间，结束时间等）收集起来，持久化到数据库，并在页面上统一展示。其中最基本的也是最重要的部门就是从每个服务器上获取SQL信息，然后进行相应的处理。最初的程序伪代码如下所示：

if (SQL完成) {
    //存入数据库
} else {
    while (true) {
        //获取最新SQL查询状态
        if (SQL完成) {
            //存入数据库
            break;
        }
    }
}

只需要从服务器获取SQL最新的查询信息，然后判断该SQL是否执行完成，执行完成之后存入数据库中。处理逻辑也非常简单，一个if-else判断就能搞定。但是在往后开发的时候，需求又进行了更新，还有一些其他的情况需要进行处理，此时程序的伪代码如下所示：

if (SQL完成) {
    //存入数据库
} else {
    while (true) {
        //获取最新SQL查询状态
        if (SQL完成) {
            //存入数据库
            break;
        } else if (SQL正在执行) {
            if (执行时间 > 执行时间阈值) {
                //取消SQL执行
                //存入数据库
            }
        } else if (SQL等待) {
            if (等待时间 > 等待时间阈值) {
                //取消SQL等待
                //存入数据库
            }
        }
    }
}

在新的处理逻辑中加入了两个新的判断分支：分别是执行超时和等待状态。对于这两种情况我在这里就不解释其含义了。对于执行超时，用户可以设置一个执行时间的阈值。当SQL执行时间超过该阈值时，就取消该SQL的执行，以释放资源；而对于等待状态，当SQL已经在等待超时状态时，如果等待时间超过该阈值，则取消该SQL的等待，直接进行后续处理。
对于每个服务器上的每一条SQL查询都会进行这样一个循环判断，从伪代码就不难看出，逻辑处理比较复杂，而且代码看起来不优雅。此时，我们可以明显发现，其实上面的各个if-else分支判断，本质上就是一个SQL的各个状态之间的转移。因此我们很自然的就想到了使用状态机编程的方式，对这部分代码进行重构。

开始重构

与一般的编程方法不同，状态机编程主要就是将程序划分为各个不同的状态，并且定义了每个状态对应的行为以及相关的状态转换关系。说起来可能比较抽象，下面就结合上面所说的例子，来具体了解下什么是状态机编程。
首先，对于上面的伪代码我们可以看到，SQL在执行的过程中一共有四种状态：完成，运行中，执行超时和等待超时。这几种状态之间有相互转换的可能，例如运行中的SQL可能完成，也可能执行超时或者等待超时。因此，我们根据SQL的这些执行状态定了如下的枚举：

public enum QueryStatus {
    START, RUNNING, WAITING, TIMEOUT, FINISH, STOP
}

下面来对上面的各个执行状态进行解释：
- START：表示刚开始时，从服务器获取SQL的查询信息；
- RUNNING：表示SQL正在执行过程中；
- WAITING：表示此时SQL已经处于等待的状态；
- TIMEOUT：表示SQL执行超时或者等待超时；
- SUCCESS：表示SQL执行完成，此时可以持久化到数据库中；
- STOP：结束状态，不做具体操作。
解释完了各个状态的含义之后，我们来看看各个状态之间的状态转换图：

关于每个状态之间的状态转移情况就再赘述了，大家只要知道这些状态之间有这样的转换关系即可。
下面为了使用状态机编程，还定义了另外一个类用于保存SQL的状态及查询信息，如下所示：

public class QueryEntity {
    private QueryStatus status;
    private QueryInfo info;
    //省略余下的get和set方法
}

其中，QueryInfo就是用于保存SQL的查询信息。然后，我们就可以根据上面的状态转换图进行编码了，这里只展示关键部分的代码，对于相关的上下文则略去：

public void handle(QueryInfo info) {
    QueryEntity entity = new QueryEntity(QueryStatus.START, info);
    while (entity.getStatus() != QueryStatus.STOP) {
        switch(entity.getStatus()) {
            case START:
                start(entity);
                break;
            case RUNNING:
                running(entity);
                break;
            case WAITING:
                waiting(entity);
                break;
            case TIMEOUT:
                timeout(entity);
                break;
            case FINISH:
                finish(entity);
                break;
            default:
                logger.error("Unknown query status: ");
                break;
        }
    }
}

private void start(QueryEntity entity) {
    //初始的获取信息操作
}

private void running(QueryEntity entity) {
    //运行状态的处理逻辑，如果执行超时则转换为TIMEOUT；否则为FINISH
}

private void waiting(QueryEntity entity) {
    //等待状态的处理逻辑，如果等待超时则转换为TIMEOUT；否则为FINISH
}

private void timeout(QueryEntity entity) {
    //取消SQL的执行或者等待，然后转换为FINISH
}

private void finish(QueryEntity entity) {
    //SQL处理完毕，执行持久化操作
    //只有在这里，状态才会转换为STOP，并退出状态机
}

至此，本次重构就已经完成。我们可以看到，使用状态机编程方法进行重构之后，代码逻辑变得更加清晰和易懂，而且状态之间的转换也不容易出错。代码也更加优雅。然后就是相关的代码review和测试过程了。这就不是本文的重点了。

延伸学习–状态模式

状态机最早并不是来源于软件开发，但是现在的应用非常广泛，例如音乐播放器之间的各个状态变换也是使用了状态机编程。在设计模式中有一种状态模式，就是使用了这种思想。
定义：状态模式允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
这里一共包含了两部分的含义：

1. 状态模式将状态封装成了独立的类，并通过代表当前状态的对象来进行相应的动作；
2. 从用户的角度来看，如果对象能够完全改变其行为，那么该对象是从别的类实例化来的。然而，状态模式是使用组合，通过引用不同的状态对象来造成类改变的假象。

下面来看看状态模式的类图：

从类图可以看出，我们在上面所使用的状态机编程与这里有一些不同。状态模式首先抽象了一个状态类的接口，然后为每个状态实现了一个具体的状态类。下面就根据状态模式的定义将上面的例子改为状态模式的编码。
首先，定义一个抽象状态接口，并定义一些通用的方法，然后对每一种状态都实现一个具体的状态类。这里只写了START和STOP对应的状态类作为演示：

public interface State {
    public void handler(QueryInfo queryInfo);
}

public class StartState implements State {
    QueryContext context;
    public StartState(QueryContext context) {
        this.context = context;
    }

    public void handler(QueryInfo queryInfo) {
        //和上面的start()方式执行相同的处理逻辑
        //可以通过context.setState()来改变状态
    }
}

public class StopState implements State {
    QueryContext context;
    public StopState(QueryContext context) {
        this.context = context;
    }

    public void handler(QueryInfo queryInfo) {
        //退出本次处理
        context.setStop = true;
    }
}

下面就是查询对应的Context类，通过调用Context的handler方法可以将动作委托给具体的状态来执行：

public class QueryContext {
    State startState;
    State runningState;
    State waitingState;
    State timeoutState;
    State finishState;
    State stopState;
    State state = startState;
    boolean isStop;

    public QueryContext() {
        startState = new StartState(this);
        runningState = new RunningState(this);
        waitingState = new WaitingState(this);
        timeoutState = new TimeoutState(this);
        finishState = new FinishState(this);
        stopState = new StopState(this);
        isStop = false;
    }

    public void handler(QueryInfo queryInfo) {
        state.handler(queryInfo);
    }

    public void setState(State state) {
        this.state = state;
    }

    public State setStop(boolean isStop) {
        this.isStop = isStop;
    }

    public State isStop() {
        return isStop;
    }
}

下面是一个简单的测试类，用于验证我们的这个状态处理机：

public class QueryContextTest {
    public static void main(String[] args) {
        QueryContext context = new QueryContext();
        QueryInfo queryInfo = GetTestQueryInfo();
        while (!context.isStop()) {
            context.handler(queryInfo);
        }
    }
}

可以看到，使用状态模式对上面的例子进行修改之后，代码量反而增加了不少，而且逻辑看上去也复杂了。所以说，上面的情况并不适合于使用状态模式进行处理。状态模式比较适合对于每种状态，都有好几个操作进行，而上面的例子中，就只有一个handler方法。因此，只需要定一个状态枚举即可。在实际开发过程中，我们也应该灵活处理问题，而不是生搬硬套。