最近寫了很多的占星文章，不知道有沒有人不習慣呀？為了擔心有些讀者無法適應，同人在此寫了一篇有關軟體開發的文章以中和主題，並用來分享我對彈性分類策略的設計心得。 許多的資料查詢，常會根據某些不同的分群觀點來將資料作分類。例如交易資料中的「產品分類」或是「單據種類」，使用者經常會希望將這些欄位當作查詢條件，讓他們可以找出相同產品分類或是單據分類的資料。 然而，實際上的查詢作業需求可能會比較複雜，也就是使用者可能會需要在一次資料查詢的結果，希望把不同資料分類，但彼此的分類之間卻同屬於相同分類群組的資料顯示在一起。我們可以新增資料分類群組的欄位，並依據資料分類來設定其分類群組的內容。這種作法在資料查詢方面的實作上非常簡便，但缺點則是要在資料的維護上額外花費一些成本。 因為這樣的設計會造成資料欄位的遞移相依，違反資料正規化的原則。當資料分類內容修改時，分類群組的內容也要跟著修正；而實際上很可能會因為程式的瑕疵或系統出現異常現象而造成資料不完整或缺乏一致性的風險。 而且，很多依據分類群組集中查詢的需求往往是在專案後期才提出來，如果開發者並不願意因此改動資料庫結構，要如何在不增加群組欄位的情況下，實作出依據分類群組集中查詢的功能呢？ 答案當然是將分類群組欄位化成對應的查詢語法或群組欄位的顯示內容，這樣會讓查詢資料的實作程式變得複雜些。因為程式實作者除了必須知道資料的來源之外，尚須瞭解群組欄位與資料分類之間如何轉換。而當相同的查詢需求散布在系統各個程式之間時，就會增加程式開發的複雜度與出錯機率。尤其使用者可能會視作業方式來增加分類群組的需求，開發者應該如何運用設計的彈性，以降低程式開發沒有必要的複雜度呢？ 同人在此提出一種設計手法，運用彈性分類群組策略的設計來解決以上的問題
上次提到用服務層的概念整合業務流程與功能性交易，並指出因應交易流程整合的非同步呼叫考量的兩種技術實作方式，也就是 database sharing 與 message queue 的不同做法。兩種做法會殊途同歸，最後會依據處理狀態，呼叫後端的服務進行後續系統作業。 既然兩種做法會殊途同歸，那麼在設計上，可不可以設計出同時適用不同實作方法的非同步機制呢？依據這樣的設計思路，我們會希望把會變動的部分用界面封裝起來，如下圖所示。 在上圖的設計中，我們定義了一個 ServiceEvent，用以記錄交易識別碼、交易階段代碼及流程代碼等資訊，其中流程代碼的目的可提供系統進行更精細的控制，而交易識別碼及交易階段代碼則是用以取得交易目前處理狀態以讓系統繼續處理交易的後續動作。 ServiceEvent 由 EventAdvice 產生，並由 EventListener 讀取，而傳送及接收 ServiceEvent 的任務則交由實作 EventSender 及 EventReader 的類別來處理，如此便可達到不會因為不同的實作方式而更動到設計。
在 OO 社群中，由人稱 GoF 所著的《design Patterns: Elements of Reusable Object-Oriented Software》[1]被認為是物件導向軟體設計的重要典範，但最近在 InfoQ中文站，有一篇文章的主題是 〈InfoQ: “四人帮”的设计模式经得起时间的考验么？〉，提到這本書最近被人質疑已經與時代的發展脫節，書中解決問題的方式已經可以由新的語言來做更好的處理，用書中的設計樣式[2]來解決設計問題還會增加不必要的複雜度。 這篇文章提到對設計樣式的反面意見主要包括了設計樣式是一種複雜性的表現形式、對設計樣式的樣板式代碼（boilerplate code）的需要，代表在設計思路上的問題，也就是開發者所使用的語言基礎結構出現問題的信號、以及設計樣式阻礙了《A Pattern Language – Towns, Buildings, Construction》這本建築架構思想的傳播，本書是被公認是激發了資訊科學領域內的設計樣式運動。 附註 中文版為由葉秉哲譯（2001），《物件導向設計模式》，美商普林帝斯霍爾國際出版。[↩]有關 design pattern 一詞，中文有兩種翻譯方式，設計模式與設計樣式，同人習慣用「設計樣式」來稱呼之。[↩]
一開始我們並不著眼於 design pattern 上，而是隨著設計的不同考量上，藉由逐步發現與解決設計問題的過程中，讓 design pattern 躍然成形。讓問題來主導設計，而非讓設計使問題複雜化。
此舉並非意味著我們要自己造輪子，用 QueryCriteria 取代 Hibernate 的 HQL 或 Criteria，而是要建立一個共通的表述方式，讓使用不同的永續框架都能採用一致的作法來滿足需求。我們的目的是利用永續框架，但卻不受特定的框架所限制。
將迴圈控制與資料處理的概念區隔開來，讓程式碼的結構更具有彈性與穩定性。把程式碼組織起來，它們將自然形成一個充滿驚奇及富有彈性的世界，並為軟體注入鮮活的生命力，而在演化過程中，我們用參與調適取代控制預測，也讓自已不斷地成長與接受改變，我想這是軟體開發最饒富趣味的過程吧。
程式設計的基礎，並不在學校的課程，而在程式設計者的實際體悟，要培養紮實的程式寫作基礎，不論你是不是科班生都一樣，除了由招熟而漸悟懂勁的道理外，請再切記：練拳不練功，到老一場空。
在不理想的軟體開發環境中，產能與產出多半不能平衡。太過重視產能，容易使軟體開發停留在技術宏觀及理論層次，但這樣會缺少的相對的有效產出，所有概念都只是空談；但如果太強調產出，我們很難適應環境變遷所造成的影响，浪費我們投入的產能，做出來的東西都是無用之物。產能與產出不能平衡時，勢必造成報酬遞減現象，而只有兩者相互回饋，才能形成技術與經驗的增強環路，達成報酬遞增的現象。
最新迴響