Strategy Pattern

200
-1

Published on

Design pattern, Strategy

Published in: Software
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
200
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Strategy Pattern

  1. 1. Strategy Ted
  2. 2. • 考慮變化的設計 – 針對介面設計程式而不要針對時做來設計程式 – 優先使用聚合,而不是類別繼承 – 考慮設計中甚麼是可變的,在變化發生時不需 重新設計
  3. 3. 國際電子商務的例子
  4. 4. • Switch Creep
  5. 5. • 難以閱讀 • 難以理解 • 很容易有遺漏
  6. 6. • 使用繼承的方式解決? • 看起來不錯?
  7. 7. 新的需求… • 貨運服務 • 國外可能沒有黑貓宅配或超商取貨
  8. 8. What can we do? • Override Rule的method,使他不做任何事 • 這樣做真的對嗎?
  9. 9. • 而且這樣做會造成冗餘的程式碼,假設加 拿大跟日本的貨運是使用同樣的方式,但 是我們並無法將程式碼寫在同一個地方(使 用override),即使可以也會造成弱內聚(使 用Switch)
  10. 10. 是否有其他的做法 • 想想開頭說的考慮變化的設計 – 尋找變化並封裝他 – 將這個類別包含在另一個類別中
  11. 11. • 解決了冗餘的程式碼也不需使用switch來判 斷要使用哪個rule
  12. 12. • 意圖:可以根據所處上下文使用不同的規則 或演算法 • 問題:隊所需演算法的選擇取決於發出請求 的對象 • 解決方案:將對演算法的選擇和實作分離
  13. 13. • 參與者與協作者 – Strategy指定了如何使用不同的演算法 – 利用各ConcreteStrategy實作 – Main 透過type選擇使用的演算法(多型) • Strategy = new FirstStrategy() • Strategy = new SecondStrategy()
  14. 14. • 效果 – Strategy定義了一系列的演算法 – 可不使用Switch – 必須使用同樣介面呼叫演算法 • 實作 – Sample code
  15. 15. 實作經驗 • 在使用getTax的範例中,英國某個年齡層的 人並不需付食物消費稅。 • 如何解決這個問題
  16. 16. • 將customer物件傳給rule物件 • 將customer的成員傳給rule物件 • 將this傳給rule物件 • 即使需要修改,但是我們還是可預期修改 幅度不致於太大,而且不太可能引入新問 題
  17. 17. • 封裝邏輯 • 簡化測試
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×