最近寫了很多的占星文章，不知道有沒有人不習慣呀？為了擔心有些讀者無法適應，同人在此寫了一篇有關軟體開發的文章以中和主題，並用來分享我對彈性分類策略的設計心得。
許多的資料查詢，常會根據某些不同的分群觀點來將資料作分類。例如交易資料中的「產品分類」或是「單據種類」，使用者經常會希望將這些欄位當作查詢條件，讓他們可以找出相同產品分類或是單據分類的資料。
然而，實際上的查詢作業需求可能會比較複雜，也就是使用者可能會需要在一次資料查詢的結果，希望把不同資料分類，但彼此的分類之間卻同屬於相同分類群組的資料顯示在一起。我們可以新增資料分類群組的欄位，並依據資料分類來設定其分類群組的內容。這種作法在資料查詢方面的實作上非常簡便，但缺點則是要在資料的維護上額外花費一些成本。
因為這樣的設計會造成資料欄位的遞移相依，違反資料正規化的原則。當資料分類內容修改時，分類群組的內容也要跟著修正；而實際上很可能會因為程式的瑕疵或系統出現異常現象而造成資料不完整或缺乏一致性的風險。
而且，很多依據分類群組集中查詢的需求往往是在專案後期才提出來，如果開發者並不願意因此改動資料庫結構，要如何在不增加群組欄位的情況下，實作出依據分類群組集中查詢的功能呢？
答案當然是將分類群組欄位化成對應的查詢語法或群組欄位的顯示內容，這樣會讓查詢資料的實作程式變得複雜些。因為程式實作者除了必須知道資料的來源之外，尚須瞭解群組欄位與資料分類之間如何轉換。而當相同的查詢需求散布在系統各個程式之間時，就會增加程式開發的複雜度與出錯機率。尤其使用者可能會視作業方式來增加分類群組的需求，開發者應該如何運用設計的彈性，以降低程式開發沒有必要的複雜度呢？
同人在此提出一種設計手法，運用彈性分類群組策略的設計來解決以上的問題，請參考如下所示的設計模型。
此設計模型定義了分類群組類別 TypeGroup，運用此類別可產生新的分類群組，指定群組名稱、說明、以及其分群依據的資料分類欄位。而為了將分類群組的查詢及資料顯示演算法封裝起來，我們運用 Stratrgy Pattern 封裝了 getFindCriteria()、及 getGroupValue() 等操作界面成為 GroupStrategy 界面，而將查詢及顯示分類群組的工作交由實作此界面的類別。
於是，我們便可抽離查詢及顯分類群組的操作，將它們委託給隱藏於內的策略物件。而此策略物件則可視實際的需要加以抽換，而主要的資料查詢程式則不會受到群組演算法的更動而受到影響。
當然策略物件我們可運用 Abstract Factory 產生，但更簡便的作法則是可交由 spring framework 來管理其策略物件的生命期。如此，彈性分類群組策略的設計更能夠享受到元件化開發的好處了。
