摘要：有限狀態(tài)機可以歸納出四個要素現(xiàn)態(tài)即當前的狀態(tài)。但狀態(tài)模式還有一點需要注意到，當采用子類繼承實現(xiàn)多種具體狀態(tài)的時候，注意控制狀態(tài)的數(shù)量，以免出現(xiàn)子類數(shù)量膨脹的現(xiàn)象在使用或等更完整面向對象語言時。

業(yè)務代碼開發(fā)久了，偶爾看看設計模式，總會讓自己有一種清新脫俗的感覺。總想把這種感覺記下來，但一想到要先起個恰如其分的標題和開頭，就讓我有一種百爪撓心的糾結，所以遲遲沒有開始。今天起更新我學習設計模式筆記的原因，就好像是，你喜歡一個女孩久了，卻總不表白，難道不怕被別人截胡了么！

首先我們來一起設想一些場景：

程序員們在等電梯的時候，聊天頻率最高的一個話題，是不是電梯調(diào)度算法呢。寫字樓的幾部電梯到底是分單雙層運力快，還是高低層運力快？當你按下電梯時，是就近樓層的電梯視來接你，還是自顧自的先上后下順帶來接你？

開車來到路口，對紅綠燈亮滅的長短是否曾有過習慣性的吐槽

除了電梯調(diào)度、紅綠燈控制，軟件設計和業(yè)務開發(fā)中，類似諸如狀態(tài)切換的問題不難遇到。他們的共同點是：場景存在多個狀態(tài)，狀態(tài)改變時會觸發(fā)對應的不同處理方法，狀態(tài)間切換又存在諸多約束和限制。

面對這種場景，你腦海里的第一解決方案是什么？條件分支if...else或者switch...case么？其實應當視具體場景復雜度來看，如果狀態(tài)少邏輯簡單，條件分支力所能及。但倘若狀態(tài)較多，邏輯復雜，又存在諸多特殊情況的約束限制，本文將介紹的狀態(tài)模式歡迎來解一下。

定義：當一個對象的內(nèi)在狀態(tài)改變時，允許改變其行為，這個對象看起來像是改變了其類

我們先來看下傳統(tǒng)面向對象語言的類圖，后面再細說前端js中該如何應用

對于一個if...else處理的長流程，我們可以抽象成多個狀態(tài)的切換，不同具體的狀態(tài)繼承自一個抽象狀態(tài)接口。場景類維護當前狀態(tài)對象的一個實例，以及狀態(tài)切換間的約束關系。

這樣做的好處是將狀態(tài)的獲取和狀態(tài)的切換進行了分離，一個具體的狀態(tài)類只處理本狀態(tài)相關的邏輯，符合單一職責原則，后期如果新加狀態(tài)只需要新建具體的狀態(tài)類，符合開放封閉原則。

JavaScript沒有抽象接口類的概念，所有類圖也大大簡化，如下：

State類為狀態(tài)類，包含狀態(tài)值以及狀態(tài)改變時具體的處理方法。Context類為場景類，維護狀態(tài)間的約束關系以及控制觸發(fā)狀態(tài)的切換。
下面我們看下代碼，讓概念平穩(wěn)落地：

// 定義狀態(tài)類
class State {
    constructor(color) {
        this.color = color
    }
    // 處理該狀態(tài)下具體邏輯
    handle(context) {
        console.log(`turn to ${this.color}`)
        context.setState(this)
    }
}

// 定義場景類
class Context {
    constructor() {
        this.state = null
    }
    setState(state) {
        this.state = state
    }
    getState() {
        return this.state
    }
}

測試代碼如下：

const ctx = new Context()
// 實例出具體狀態(tài)
const red = new State("red")
const green = new State("green")
const yellow = new State("yellow")
// 綠燈亮
green.handle(ctx)
console.log(ctx.getState())
// 紅燈亮
red.handle(ctx)
console.log(ctx.getState())
// 黃燈亮
yellow.handle(ctx)
console.log(ctx.getState())

狀態(tài)模式脫胎自有限狀態(tài)機（Finite-State-Machine），這個數(shù)學模型描述了有限個狀態(tài)，以及這些狀態(tài)之間轉移和動作的行為，是一種對象行為建模的工具。類似下圖就是一種有限狀態(tài)機：

其實我們在處理業(yè)務邏輯時，經(jīng)常打交道的各種事件和狀態(tài)切換，寫的各種if...else和switch...case都是有限狀態(tài)機模型，只是平時沒有意識到吧了。在處理較為復雜的邏輯時，考慮把業(yè)務邏輯抽象成一個有限狀態(tài)機模型，常常會是代碼邏輯清晰，結構規(guī)整。

有限狀態(tài)機可以歸納出四個要素：

現(xiàn)態(tài)：即當前的狀態(tài)。

條件：又稱為“事件”。當一個條件被滿足，將會觸發(fā)一個動作，或者執(zhí)行一次狀態(tài)的遷移。

動作：條件滿足后執(zhí)行的動作。動作執(zhí)行完畢后，可以遷移到新的狀態(tài)，也可以仍舊保持原狀態(tài)。動作不是必需的，當條件滿足后，也可以不執(zhí)行任何動作，直接遷移到新狀態(tài)。

次態(tài)：條件滿足后要遷往的新狀態(tài)。次態(tài)是相對于現(xiàn)態(tài)而言的，次態(tài)一旦被激活，就轉變成新的現(xiàn)態(tài)了。

Tips：避免把某個程序動作當作是一種狀態(tài)來處理，動作是不穩(wěn)定的，即使條件沒有觸發(fā)，一旦動作執(zhí)行完也就結束了；但狀態(tài)是穩(wěn)定的，如果沒有外部條件觸發(fā)，狀態(tài)會一直持續(xù)下去。

介紹了有限狀態(tài)機，我們當然可以通過上面介紹的狀態(tài)模式的方式，來將這種模型工具應用到我們的代碼開發(fā)當中。但是你有沒有注意到一個問題？對，代碼不夠優(yōu)雅，略顯簡陋，不能忍！

接下來介紹一個優(yōu)雅的有限狀態(tài)機實現(xiàn)類庫javascript-state-machine，接下來使用這個類庫簡單實現(xiàn)一個Promise的功能，來看一下如何使用。

首先回顧一下Promise的特點：

Promise是一個類。

Promise在實例初始化的時候需要傳入一個函數(shù)。

傳入的函數(shù)需要接收resolve和reject兩個函數(shù)，成功的時候調(diào)用resolve，失敗的時候調(diào)用reject。

Promise實例出的對象有一個then方法，可以進行鏈式操作。

Promise擁有三種狀態(tài)：pending、fulfilled、rejected，可以從pending->fulfilled，或pending->rejected，但不能逆向。

接下來上代碼實現(xiàn)一下

// 狀態(tài)機模型
const fsm = new StateMachine({
    // 初始狀態(tài)
    init: "pending",
    // 狀態(tài)遷移規(guī)則，name,from,to的名字盡量別同名
    transitions: [
        { name: "resolve", from: "pending", to: "fulfilled" },
        { name: "reject", from: "pending", to: "rejected"}
    ],
    methods: {
        onResolve(state, data) {
            data.successFn.forEach(fn => fn())
        },
        onReject(state, data) {
            data.failFn.forEach(fn => fn())
        }
    }
})

// 定義Promise
class MyPromise {
    constructor(fn) {
        this.successFn = []
        this.failFn = []
        fn(
            () => { fsm.resolve(this)},
            () => { fsm.reject(this)}
        )
    }
    then(successFn, failFn) {
        this.successFn.push(successFn)
        this.failFn.push(failFn)
        return this
    }
}

本文介紹了狀態(tài)模式和有限狀態(tài)機的概念，以及才開發(fā)中優(yōu)雅使用的姿勢javascript-state-machine，并通過用其簡單實現(xiàn)了Promise的基本功能，演示了如何使用。

其實重點還是狀態(tài)模式，通過本文介紹可以很明顯地感受到其優(yōu)點：

結構清晰，避免了過多的if...else或switch...case的使用，降低了程序的復雜性，提高了系統(tǒng)的可維護性。

很好遵循了開放封閉原則和單一職責原則。

記得Martin在《重構》中，提到一個壞的代碼味道“Long Method”，當你遇到一個方法中包含了一大堆邏輯，做了很多事的時候，你就應該嗅探到一股惡臭味，怎么去修改，或許考慮使用狀態(tài)模式是一條途徑。

但狀態(tài)模式還有一點需要注意到，當采用子類繼承實現(xiàn)多種具體狀態(tài)的時候，注意控制狀態(tài)的數(shù)量，以免出現(xiàn)子類數(shù)量膨脹的現(xiàn)象（在使用TypeScript或Java等更完整面向對象語言時）。