html5引擎開發 -- 引擎消息中心和有限狀態機 - 初步整理 一

一 什麼是有限狀態機

       FSM （finite-state machine），又稱有限狀態自動機，簡稱狀態機，是表示有限個狀態以及在這些狀態之間的轉移和動做等行爲的數學模型。他對於邏輯以及時序的控制能起到很是重要的做用。

代碼主要看的是什麼？邏輯！全部的設計模式無非是讓程序邏輯變得更加利與維護，利於優化，利於升級而已。

那麼能不能把業務邏輯整理出來統一操做呢？

你能夠理解狀態機就是幹這個的（固然不只僅是這樣）。這樣一來只要將一個業務當作一個狀態機，有N中狀態，而後統一來控制這些狀態時的操做。

你們都用過dom事件綁定，是否是某種狀態時候就會觸發某種事件？這明顯也是狀態機的概念能解釋的。還有觀察者模式或者說是訂閱發佈模式，抑或是jquery的deffered和pomise，甚至是各類同步編程模塊（windjs）等等等等。仔細想一想也基本上都是一樣的原理：即根據不一樣的消息，誘發註冊的相應回調。區別僅僅是怎麼註冊或者說生成支持各自機制的對象而已。

將各類業務狀態寫在一塊兒集中管理的好處是什麼？就是你整個流程會變得無比的清晰，一目瞭然！而再也不須要將業務邏輯寫的處處都是。方便了總體業務邏輯的管理。（後期會抽象出消息機制概念，完全解放模塊之間的耦合，敬請期待）

二 狀態機的一些概念

         1 狀態轉換

從一個狀態切換到另一個狀態被稱爲狀態轉換

         2 觸發事件

狀態改變而引發它的事件稱爲觸發事件.，而觸發時間徹底能夠集中在一塊兒定義，方便管理.業務流程一目瞭然。

 

三 會用在哪些場景

         狀態機能夠用在任何能抽象出業務流程的地方，大到頁面加載，引擎加載，購物流程，小到tab標籤，顯示隱藏控件，等等地方。

         會不會常常被一大堆的回調函數，異步函數回調之間的邏輯高的頭昏眼花？抽象出一個狀態機來，外部的各類操做（異步，同步，回調）只須要改變這個狀態機的狀態就能夠執行相應的操做了。

四 舉個例子

         試想一下，好比咱們加載引擎的業務流程：

                  --初始化引擎（initcore）

                  --初始化模板（inittpl）

                  --獲取數據（initdata）

                  --初始化頁面（initpage）

                  --初始化頁面成功（pageok）

         咱們能夠將這個業務流程生成一個狀態機，好比叫「app」，那麼咱們須要作的是什麼呢？

咱們只須要將這些狀態賦予這個叫作「app」的狀態機對象，同時生成一個狀態改變時的觸發事件管理器。就能夠方便並集中地來管理整個業務流程了。邏輯代碼展示大概以下：

var fsm = FSM.create([’initcore’,’inittpl’,’initdata’,’initpage’,’pageok’],
　　　　　　　　function(from,to,data){
　　　　　　　　　　switch（to）{
　　　　　　　　　　　　case ‘initcore‘:
　　　　　　　　　　　　break;
　　　　　　　　　　　　case ‘coreok’:
　　　　　　　　　　　　break;
　　　　　　　　　　　　　….
　　　　　　　　　　　　case ‘pageok’:
　　　　　　　　　　　　break;
　　　　　　　　}
　　　　　　});

 

這樣一來整個app加載流程就會一目瞭然，而不論是在異步中仍是頁面回調中須要業務變動時，只須要改變對應狀態機的狀態就會執行相應的邏輯。好比：

         fsm.change(‘pageok’);

咱們能夠稱之爲面向業務的狀態模型，也能夠稱之爲狀態模式。

 

下面，咱們再來看看消息中心的想法。

 

五 關於狀態機爲核心的消息中心抽離

         5.1讓咱們看看之前的模塊式開發

         之前引擎和模塊，模塊和模塊之間，通常都是互相直接調用接口，也就是api模式。這就是面向對象基本模式了，每個模塊都是一個對象，對外開放了不少接口，其餘對象只須要調用目標對象的相應接口就能夠執行相應的邏輯。目前來講，基本上都是這樣的設計模式，這種方式爲咱們帶來了很大的便利（圖）。

 

 

 

5.2提出問題

可是這樣無法避免的一個問題就是，在一個模塊內部須要直接調用另一個模塊的api，你中有我，我中有你。試想一下，若是另一個模塊不存在，接口不存在呢，或者接口返回錯誤的狀況下該怎麼辦呢？不至於每一個調用其它模塊的地方所有都寫上容錯吧，那麼代碼基本無法看了。

那麼咱們就該想一想了，是否是應該有這樣一套機制呢，暫時叫作調度中心,咱們簡單設想一下它應該有一下功能：

1 調度中心能統一的管理引擎以及各個模塊之間的相互調用，以方便記錄當前應用運行的的各類實時操做。

2 全部的模塊不會直接調用其餘模塊的接口，而是告訴調度中心，我要調哪一個模塊的哪一個方法，並提供必要的參數,調度中心會解析消息並調用相應的模塊，固然必要的錯誤處理機制是必須的。

3 每一個模塊必須有相應的消息處理機制，有調度中心統一方法「吃入」模塊，固然必要的配置文件是必須的。

這就是咱們說的消息機制。O(∩_∩)O~

 

5.3什麼是消息機制

   

    每一個引擎都會有不少不少的模塊，好的引擎模塊間的耦合會比較鬆，可是大多數引擎模塊之間都是結合的很緊密的。

    消息，不少狀況下都跟通訊相關。那麼消息機制應用到引擎中是什麼樣子呢？（圖）

 

 

5.4要注意的問題

   

1    流程上增長了複雜度，開發一個高效的消息中心很重要

2    每一個模塊須要註冊進消息中心

3    消息錯誤時 要有統一處理機制

 

 

總結：

       想一下，狀態機做爲消息中心的核心引擎來實現消息中心思想，是否是很給力呢？消息中心能夠實現消息隊列，也能夠切入aop設計模式來實現消息中心的各類功能擴展。