M15 入口、流程與動作的沾粘現象

至今為止我覺得程式設計最需要遵守的原則，是把相同目的的程式碼抽取到共同的地方，而且應該只有一份。短短的一句，但是如何切割才是理想的共用部分？如何佈置才讓所有人員都很快知道應該共用的東西在哪裡？

流程與動作是應該分離的部分，程式之所以難改大多是因為數個動作被寫成一個方法，後來卻有修改那個方法的需要（尤其是在那數個動作間要插入其他動作時）。這個時候若沒有正確的追溯，就無法清楚在其他地方如何使用這個方法，無法兼顧所有使用而只看著眼前的需要去修改，就很容易造成其他使用同樣方法的功能問題。許許多多side effect（改好這個卻冒出別的）與defect repoen（已經改好的問題又再度出現）等讓使用者無法忍受的嚴重現象就會跟著發生。

對於Method功能需求的實作完全由流程與動作囊括，但是在什麼地方使用是由入口來決定；以這個現象來看，入口與流程應該是不同角度的思考。想像在使用者按組合鍵驅動某功能的場合，如果這個功能的流程寫在組合鍵的listener裡頭，如果使用者想要在按某按鈕時也要驅動該功能的話，勢必得要切開程式碼作些調整或是copy-paste了。

有個系統把F1到F12的功能鍵寫為獨立的listener，每個方法內都直接實作了特定的系統功能。後來同樣的系統在另一個客戶那邊使用，可是有些按鍵的對應功能需要改變，結果在這種情況下只能另外複製一個Class並且搬移“要變更對應的所有程式碼“，再設定Class Name來整個替換使用。同樣的入口、同樣的系統功能，結果產出了兩個幾乎相同的Class。雖然結果符合所有客戶的需要，但是這樣的作法適當嗎？

註：方法的入口有兩種考量。一種是只提供一種作法，讓進入的變化在專案那裡處理；另一種則把變化放置在傳入的變數中，進入方法後由內部加上一層入口來控制要進行哪個流程。一般狀況下以第一種最多，但是我現在會選擇第二種。