T09 動靜分離──Flow與Action的分工

在無法或不想投入足夠時間開發功能的時候，一個Interface Method的實作極可能會成為直接完成功能的型態──所有大大小小要做的步驟都被堆在一個Method，而且沒有完善的例外控制。如果完成功能的技術瓶項繫在少數幾個人手上但是都忙到無法投入太多時間，那麼這個功能的潛在問題也相對較多。

曾經被派去寫一款連接com port的存摺印表機，使用Java Comm API送出控制碼來操作印表機的工作。剛開始都花時間在研讀規格與測試要送出什麼樣的資料才會讓印表機動作，把控制動作做完後臨時被派去另一個專案，接下來的流程處理就轉交給另一位同事處理。在這個案例裡，我負責讓每一個分解動作（Action）能夠運行，另一位同事則負責讓每一個API的流程控制（Flow）趨於完善。

換句話說，把Interface Method視為元件功能的同時，Flow裡要做的就是元件功能的ＳＡ，Action裡要做的元件功能的ＳＤ。在Flow裡依功能的需要挑選Flow裡的其他方法或是Action裡的方法來組合出流程，此時僅在邏輯上設計所需的動作可以不用管Action裡是如何完成而；Action裡則專注於如何完成該動作與傳回動作的結果，同樣不用管Flow的用法。

在這個觀念之下，Flow除了呼叫其他方法之外應該只包含（且完全包含）屬於該層級的流程控制指令：
　　if…else
　　for
　　while
　　do…while
　　switch…case…default
　　try…catch
　　( ) ? :
只要Action回應的狀態正確且足夠，Component完成後就可以交給Programmer處理Unit Test發現的Flow內部的判斷錯誤──即使programmer不懂Action裡的運作原理。

更進一步地想，“元件功能越多就封裝越多的邏輯規則難以修改”的說法也可以打破。在傳統的寫法下因流程與動作的緊密結合，使得元件的邏輯規則無法修改或只能複製出來改寫內部的程式；前者造成功能不符不同需求的僵化，後者整個覆寫掉原有程式使得程式碼出現重覆與無用的狀況。在這個元件結構下，我們只要繼承原有的Abstract Flow Class就可以在只變化流程的還能重用元件內所有原有的功能，同時保有元件升級時功能與作法依然可以一起升級的便利。