Design pattern, Strategy

1. Strategy
Ted

2. • 考慮變化的設計
– 針對介面設計程式而不要針對時做來設計程式
– 優先使用聚合，而不是類別繼承
– 考慮設計中甚麼是可變的，在變化發生時不需
重新設計

3. 國際電子商務的例子

4. • Switch Creep

5. • 難以閱讀
• 難以理解
• 很容易有遺漏

6. • 使用繼承的方式解決?
• 看起來不錯?

7. 新的需求…
• 貨運服務
• 國外可能沒有黑貓宅配或超商取貨

8. What can we do?
• Override Rule的method，使他不做任何事
• 這樣做真的對嗎?

9. • 而且這樣做會造成冗餘的程式碼，假設加
拿大跟日本的貨運是使用同樣的方式，但
是我們並無法將程式碼寫在同一個地方(使
用override)，即使可以也會造成弱內聚(使
用Switch)

11. 是否有其他的做法
• 想想開頭說的考慮變化的設計
– 尋找變化並封裝他
– 將這個類別包含在另一個類別中

12. • 解決了冗餘的程式碼也不需使用switch來判
斷要使用哪個rule

13. • 意圖:可以根據所處上下文使用不同的規則
或演算法
• 問題:隊所需演算法的選擇取決於發出請求
的對象
• 解決方案:將對演算法的選擇和實作分離

14. • 參與者與協作者
– Strategy指定了如何使用不同的演算法
– 利用各ConcreteStrategy實作
– Main 透過type選擇使用的演算法(多型)
• Strategy = new FirstStrategy()
• Strategy = new SecondStrategy()

15. • 效果
– Strategy定義了一系列的演算法
– 可不使用Switch
– 必須使用同樣介面呼叫演算法
• 實作
– Sample code

16. 實作經驗
• 在使用getTax的範例中，英國某個年齡層的
人並不需付食物消費稅。
• 如何解決這個問題

17. • 將customer物件傳給rule物件
• 將customer的成員傳給rule物件
• 將this傳給rule物件
• 即使需要修改，但是我們還是可預期修改
幅度不致於太大，而且不太可能引入新問
題

18. • 封裝邏輯
• 簡化測試