[Design Pattern]Strategy和泛型

【以下先是碎碎念...可以跳過不看。】

程式碼在概念上經常就只是「演算法」與「資料結構」的具體實現。

但在程式的整體「框架」上，很難從程式碼看出來整個程式的邏輯或概念。

除非大家都使用「演算法」來描述事情...但這不可能，實際上大家還是習慣用具體需求來描述事情，例如「怎麼找出特定檔案」。

但這件需求其實是種「快速比對檔案內容」的演算法，習慣上應該沒有人會用後者來描繪、形容、跟別人溝通，即使是工程師對工程師。(天知道有多少種演算法可以做到「找出特定檔案」這件事。)

所以Design Pattern被發明了！...(可以這樣理解吧？)

可是我發現很多人把DesignPattern當成一種程式碼設計的延伸，大家還是習慣用「具體需求」來理解「何時該使用哪種Pattern」。

【碎碎念完。】



Strategy這個Pattern對我來說是個優化、或簡化程式碼的好工具。

很多習慣函數式開發的工程師經常把程式搞成一大包，一支[.java]檔動輒上萬行是小事。這種程式碼難維護不說，擴充難度更是高。

碰到這種程式碼，一般來說我都會快速的將所有的函數一刀切成兩種：「有傳入參數」和「無傳入參數」兩種。(補充說明：還要先排除這些函數之間是同名異構的「覆載」函數。)

那些「無傳入參數」的函數基本上都是直接修改全域變數...所以就把所有非static型態的全域變數複製一份獨立成一個物件，先稱為「StrategyObj1」好了！(記得在原始程式中宣告一個StrategyObj1的實做物件。)

接著就可以將所有的「無傳入參數」的函數通通獨立出來實做成一個「內部不帶參數、只有函數」的物件/類別。

為什麼「無傳入參數」的函數會用「有傳入參數」的方式實做？

首先是為了方便未來擴充。

假設某功能需要使用者輸入資料一、資料二，例如居住地的縣市和詳細路段，但未來忽然需要擴充為兩組以上的地址，則只需要把資料一和資料二包裝成一個類別，然後宣告兩個物件並分別傳入對應的UI輸入結果，就可以繼續使用同一個Strategy物件函數來處理了。

其次...這可以延續物件導向的風格！

(未完)