设计模式在实际业务设计中的落地(二)

今天是12月19日，距上一次写文章有一个星期多一点的时间，还好，希望继续按这个时间跨度坚持学习持续输出。

　　分享一个状态切换的设计，应该是能叫状态模式。

　　工作中会遇到一些场景，比如一个类似于流程的事件，在从头到尾整个事件的完成期间，会有很多种状态，而且状态是有序的，这种情况下我们如果考虑用状态模式来维护项目的话，可以避免这种if高楼大厦:

        String status = "begin";
        if ("begin".equals(status)) {
            status = "step1";
        } else if ("step1".equals(status)) {
            status = "step2";
        } else if ("step2".equals(status)) {
            status = "complete";
        }

如果将这个代码块封装成一个方法，切换状态时调用也凑合能看，不过根据以往的经历这个做法或许导致业务随时间搅乱成一锅粥，代码阅读起来会非常的博大精深，当我想加一个step3的时候我会在这里连带地改很多地方。而且如果这个业务模块在开发时频繁改动，那一不小心改错的概率会很大。
以下分享一个状态切换的设计:
假想一个业务:
 一个订单通常会有最基本的几个状态，状态的转变是有序的: 未支付 -> 已支付 -> 已完成。
 现在我想做的一个事情是，order对象只需要调用自己的nextState()方法就会进入下一个状态。

状态枚举这样写：

public enum OrderStatusEnum {

    // 待支付->已支付
    UNPAY {
        @Override
        public void nextState(Order order) {
            order.setStatus(PAID);
        }
    },
   // 支付->已完成
    PAID {
        @Override
        public void nextState(Order order) {
            order.setStatus(FINISHED);
        }
    },
  // 已完成->已完成
    FINISHED {
        @Override
        public void nextState(Order order) {
            order.setStatus(FINISHED);
        }
    };

    public abstract void nextState(Order order);
}

order:

public class Order {

    private OrderStatusEnum status;

   //初始化状态
    public Order() {
        this.status = OrderStatusEnum.UNPAY;
    }

    public void nextState() {
        status.nextState(this);
    }
}

最后Main测试:

public class TestMain {

    //Order 未支付 -> 已支付 -> 已完成
    public static void main(String[] args) {

        Order order = new Order();

        System.out.println(order.getStatus());
        order.nextState();
        System.out.println(order.getStatus());
        order.nextState();
        System.out.println(order.getStatus());
        order.nextState();
        System.out.println(order.getStatus());
        order.nextState();
        System.out.println(order.getStatus());
    }

}

我是新学到枚举还可以这么写，然后实现的状态的转变。
我觉得能学以致用就是有用，一定会派上用场。