筆記：Design pattern for Strategy & Factory Pattern

我想大家多多少少都會看過，在某一支程式或方法裡面，有「一大串」的 if-else 或 switch 程式碼。

然後每一個流程控制裡，又都再放了一堆程式邏輯。有些甚至是你細讀這些邏輯，要做的事情相似度也很高。

這些義大利麵的程式，就是讓你看了也難過，想改掉又更難過。

尤其是這些程式通常都不會有測試包起來，所以當這塊程式碼是較重要的功能時，要改也是需要勇氣跟魄力的。

因為在沒有較大的需求一定要改到這塊程式碼時，他平沒事就在那邊活得好好的，硬要去改掉的話，效益實在是偏低。

使用情境

當你發現有一段 if-else 或 switch 要一直不斷的往上加分流的程式，例如 strategy pattern 最喜歡拿來用的商品折扣範例。每當有增加一種新的折扣活動，就只能不得已在那沱噁心的程式裡面繼續加新的分流。strategy pattern 基本上就蠻適用在這種情境。

實作

一個主要的 context 裡面只管去使用一個 IStrategy 介面，而這個 IStrategy 介面要用哪一個實作（哪一種折扣活動計算），可以搭配 factory pattern 來拿到。

這樣就可以讓主流程的程式裡不用拆分那麼多分流，只管呼叫 IStrategy.Execute() 方法就好。

優點

• 不會再所有的程式邏輯都擠在同一個程式區塊裡，讀起來也累，要改的人更累。
• 將職責稍微切開來，各種不同的演算或邏輯規則可以分開（例：不同的折扣計算）。
• 要新增演算邏輯或修改既有的時候，修改範圍會明顯的限縮。
• 測試才比較好寫，不然原本的程式如果要寫測試，要不斷的讓測試程式可以進到各個分流裡。

個人經驗

strategy pattern 是一種實作的想法。並不一定要「硬刻」成標準的 strategy pattern UML 那樣的結構，一定要有 context 接 IStrategy 然後再進行呼叫。

只要是這種有很多類似的邏輯或計算處理（需要很多的程式分流或頻繁異動），都可以直接把他們「往上抽」一層，用個 Interface 來隔開。

接著再用個變數配上 factory pattern 來使用，個人覺得就都算是 strategy pattern 的核心想法了。

參考資料
Design Patterns: Strategy Pattern
軟體就該是軟的：設計模式思維實踐