【10-2】复杂业务状态的处理（从状态者模式到FSM）

　　一、概述

　　我们平常在开发业务模块时，经常会遇到比较复杂的状态转换。比如说用户可能有新注册、实名认证中、已实名认证、禁用等状态，支付可能有等待支付、支付中、已支付等状态。OA系统里的状态处理就更多了。

　　遇到这些处理，很多人可能不假思索的就用最直观的 if/else 或者 switch 来判断状态的方式。但其实除了这种简单粗暴的方式，我们还有其他更好的方式来处理复杂的状态转换。

　　二、状态判断

　　我们就以支付为例，一笔订单可能有：【等待支付】、【支付中】、【已支付】等状态。对于等待支付的订单，用户可能通过第三方支付，如微信支付或支付宝进行付款，支付完成后第三方支付会回调通知支付结果。我们可能会这样来处理：

    public void pay(Order order) 
    {
        if (order.status == UNPAID) 
        {
           order.status = PAYING;
           // 处理支付
        } 
        else 
            throw IllegalStateException("不能支付");
    }    
    
    public void paySuccess(Order order) 
    {
        if (order.status == PAYING) 
        {
           // 处理支付成功通知
           order.status = PAID;
        } 
        else 
            throw IllegalStateException("不能支付");  
    }

　　这样看起来好像没什么问题。但是假设我们允许用户多次支付完成一笔订单，于是我们需要增加一个【部分支付】状态。订单在【部分支付】状态时，可以进行下一步的支付：订单收到支付成功通知时，根据支付金额，可能会转换到【已支付】或【部分支付】状态。现在，我们不得不在pay和paySuccess里处理这个状态。

public void pay(Order order) 
{
    if (order.status == UNPAID || order.status == PARTIAL_PAID) 
    {
        order.status = PAYING;
        // 处理支付
    } 
    else 
        throw IllegalStateException("不能支付");
}    

public void paySuccess(Order order) 
{
    if (order.status == PAYING) 
    {
        // 处理支付成功通知
        if (order.paidFee == order.totalFee) 
            order.status = PAID;
        else 
            order.status = PARTIAL_PAID;
    } 
    else 
        throw IllegalStateException("不能支付");
}

　　有了支付，我们必须也要能支持退款，那就需要增加【退款中】和【已退款】状态，以及对应的退款操作和退款成功回调处理。

public void refund(Order order) 
{
    if (order.status == PAID || order.status == PARTIAL_PAID) 
    {        
        order.status = REFUNDING;        
        // 处理退款
    } 
    else 
        throw IllegalStateException("不能退款");
}

public void refundSuccess(Order order) 
{
    if (order.status == REFUNDING) 
    {        
        // 处理退款成功通知        
        order.status = REFUNDED;    
    } 
    else 
        throw IllegalStateException("不能退款");
}

　　如果用一个有限状态机（FSM：Finite State Machine）来表示目前的状态转换，那大概是这样的：

　　

　　对于状态不多、转换也不是很复杂的情况，用状态判断来处理也还算简洁明了。但一旦状态变多，操作变复杂，那么业务代码就会充斥各种条件判断，各种状态处理逻辑散落在各处。这时如果要新增一种状态，或者调整一些处理逻辑，就会比较麻烦，还很容易出错。

　　例如本例中，实际处理时可能还存在取消订单、支付失败／超时、退款失败／超时等情况，如果再加上物流以及一些内部状态，那处理起来就极其复杂了，而且一不小心还会出现支付失败了还能给用户退款，或者已经退款了还给用户发货等不应该出现的情况。这其实是一种坏味道，会造成代码不易维护和扩展。

　　三、设计模式之状态模式

　　不少人接下来可能会想到GOF的状态模式。对于涉及复杂状态逻辑的处理，使用状态模式可以将具体的状态抽象出来，而不是分散在各个方法的条件判断处理中，更容易维护和扩展。

　　状态模式一般包含三种角色，Context、State和ConcreteState。其中State是状态接口，定义了状态的操作。而ConcreteState则是各个具体状态的实现。它门的关系如下图所示：

　　 

　　下面我们尝试用状态模式实现前面的订单状态转换。首先我们需要定义状态接口，它应该包含所有需要的操作，以及每个状态对应的实现。

abstract class OrderState 
{
    public abstract OrderState pay(Order order);
    public abstract OrderState paySuccess(Order order);
    public abstract OrderState refund(Order order);
    public abstract OrderState refundSuccess(Order order);
}

//支付中状态
public class PayingOrderState:OrderState 
{ 
    public OrderState pay(Order order) 
    {
        throw IllegalStateException("已经在支付中"); 
    }
    public OrderState paySuccess(Order order, long fee) 
    {
        doPaySuccess(Order order, long fee);
        if (order.paidFee < order.totalFee) 
        {
           order.setState(new PartialPaidOrderState());             
        } 
        else 
        {
           order.setState(new PaidOrderState());
        }
    }
    public OrderState refund(Order order) 
    {
        throw IllegalStateException("尚未完成支付"); 
    }
    public OrderState refundSuccess(Order order) 
    {
        throw IllegalStateException("尚未完成支付"); 
    }
}

public class UnpaidOrder:OrderState { ... }
public class PartialPaidOrderState:OrderState { ... }
public class PaidOrderState:OrderState { ... }
public class RefundingOrderState:OrderState { ... }
public class RefundedOrderState:OrderState { ... }

　　大家可能会注意到，不是每个状态都支持所有操作的。例如上面的实现，PayingOrderState是不能refund的，PaidOrderState是不能Pay的，这里我们抛出了一个 IllegalStateException异常。当然也可以不抛异常，而是放一个空的实现。或者我们也可以定义一个 Abstract Class，把操作的默认实现都放到里面，每个状态类只需要改写自己支持的方法。

　　然后我们要实现Context，也就是我们的Order实体，它包含了一个状态字段state，通过state实现所有的状态转换逻辑。定义好了这些，支付服务的实现就很简单了。

public class Order 
{
    OrderState state = new UnpaidOrder();
    public void pay(long fee) 
    {
        state.pay(fee);
    }
    public void paySuccess(long fee) 
    {
        state.paySuccess(this, fee);        
    }
    public void refund() { ... }
    public void refundSuccess() { ... }
}

public class PaymentService 
{
    public void payOrder(long orderId) 
    {
        Order order = OrderRepository.find(orderId) 
        order.pay();
        OrderRepository.save(order);
    }
}

　　通过状态模式，我们避免了代码里出现大量状态判断，状态转换规则的实现更加清晰。不过需要注意的是，实际上状态模式并不是很符合开闭原则（Open/Close Principle），新增一个状态时，还是可能要修改已有的其他状态的逻辑。但是和状态判断的方法比起来，已经清晰并且方便很多了。

　　四、领域驱动设计之状态建模

　　前面也提到了，状态模式的另外一个问题就是，实际业务里面有很多操作其实只对部分状态有效，而状态模式要求每个状态都要实现所有操作，有时候这是没有必要的。

　　对于这种情况，在领域驱动设计里，会更建议大家使用显式状态建模的方式。也就是把不同状态的实体，建模成不同的实体类；或者每个实体类代表一组状态。

　　例如，我们可以对每种状态的订单，都定义一个实体类。不过因为可能有多种状态的订单支持同样的操作，为了抽象这类操作，我们需要先定义一些接口。

public interface CanPayOrder 
{
    Order pay();
}
public interface CanPaySuccessOrder { ... }
public interface CanRefundOrder { ... }
public interface CanRefundSuccessOrder { ... }

public class UnpaidOrder implements CanPayOrder { ... }
public class PayingOrder implements CanPaySuccessOrder { ... }
public class PartialPaidOrder implements CanPayOrder, CanRefundOrder { ... }
public class PaidOrder implements CanRefundOrder { ... }
public class RefundingOrder implements CanRefundSuccessOrder { ... }

public class PaymentService 
{
    public void pay(long orderId) {
        Order order = OrderRepository.find(orderId) 
        // 转换为 CanPayOrder，如果无法转换则抛异常
        CanPayOrder orderToPay = order.asCanPayOrder();
        Order payingOrder = orderToPay.pay();
        OrderRepository.save(payingOrder);
    }
}

　　每种状态的实体能支持的操作，都是显式定义好的。这种方式对于操作比较多，并且很多操作只对部分状态有效的情况，能够有效避免状态模式的缺点，代码更简洁清晰。

　　五、动态语言里的状态转换

　　上面的例子里，UnpaidOrder和PartialPaidOrder都可以进行 pay 操作。其实处理支付操作的时候，我们不需要知道它是 UnpaidOrder 还是 PartialPaidOrder，我只需要知道当前订单实体支持Pay操作就可以了。在 Java 这样的静态类型语言里，我们只能通过定义一些 Interface 或者 Abstract class 来处理，还是有一点点麻烦。

　　如果是动态类型语言，例如 Python、Ruby 或者 JavaScript 等，还可以通过 Duck Typing 来进一步简化。所谓 Duck Typing 就是：“如果有一只鸟，它走起来像鸭子，游起来像鸭子，叫起来也像鸭子，我们就叫它鸭子。” 意思就是说，我们可以忽略对象的类型，直接在运行时判断对象是否支持某种行为。

　　例如在 JavaScript 里，我们获取到 order 实体后，就可以通过判断是否定义了 pay 方法，然后直接调用即可，而不必了解对象到底是什么类型。

let orderToPay = order.asOrderStateEntity();
if (typeof orderToPay['pay'] === 'function') 
{
    orderToPay.pay();
} 
else 
{
    throw new ServiceError("该订单不能进行支付操作");
}

　　当然，实际会用动态语言开发这种业务系统的并不多，毕竟动态语言也会引起其他方面的一些问题。

　　六、FSM

　　不管是状态模式还是状态实体，多个状态之间的转换，还是分散在各个状态的实现里的。其实所有的状态转换都可以概括为：F(S, E) -> (A, S')，即如果当前状态为S，接收到一个事件E，则执行动作A，同时状态转换为S'。

　　Akka里面提供了一个有限状态机的框架叫FSM，通过Scala语言的模式匹配及其他一些强大特性，可以把状态转换和业务处理逻辑分离开来。具体我就不细说了，我们也没有在实际开发中使用过。但我们可以感受一下：

class OrderFSM extends FSM[State, Data] 
{
    startWith(Unpaid) // 开始时的状态是 Unpaid    
    when(Unpaid) 
    {
        case Event(Pay, data) ⇒ // Unpaid 状态时，如果收到事件 Pay，则进行支付，状态转换为 Paying
            doPay(data)        
            goto(Paying)
    }
    when(Paying) 
    {  // Paying 状态时，如果收到事件 PaySuccess，则进行支付成功处理，通过根据支付金额，转换为 Paid 或者 PartialPaid 状态
        case Event(PaySuccess(fee), data) ⇒ 
            doPaySuccess(data, fee)
            if (fee+data.paidFee == data.totalFee) goto(Paid) 
            else goto(PartialPaid)
    }
    // ...
}

　　当然，FSM 的功能远不止此，实际实现也可能会更复杂。Java 里面也有一个有限状态机的实现，叫 Squirrel，不过由于 Java 语言的限制，使用起来没有 Akka FSM 那么优雅。这里就不深入研究了，感兴趣的同学可以去了解下。

　　七、总结

　　本文简单介绍了业务系统中，处理复杂状态逻辑的几种方法。除了极其简单的情况，大家应该尽量避免使用状态判断的方式，使用状态模式或者状态建模，可以很有效的提高代码的维护性和扩展性。最后也简单介绍了动态语言对状态建模的一些优化，以及 FSM 框架。

参考链接：https://mp.weixin.qq.com/s/qe0OSiSAwVpGqYDKoWeOPQ