問題背景

有父類duck，實現了quack（叫）和swim（游泳）兩個方法

預留了display方法給子類實現

子類可能有多種，現在假設只有MallardDuck和RedheadDuck

需求：fly()

現在需要給鴨子實現fly（飛）方法

解決方法1：在父類中實現

在父類中新增fly方法給子類繼承

變化1：部分Duck不能fly

如果仍使用繼承，那麼本不該fly的Duck也能訪問到fly介面

解決方法2：在子類中進行重寫

缺點：

這種方法的缺點：（ABDF?）

且在未來的維護過程中，如果需要新增新的類，就必須反覆檢查所有介面並可能重寫部分介面

解決方法2：用介面實現

缺點：

如果未來出現需要對【fly】這個行為進行修改，比如修改fly的速度，那麼可能需要對已有的所有類都要進行修改

而且使用介面的方法本身需要在每個子類中附加實現，這樣產生了非常多的重複和冗餘的程式碼

java介面不具有實現程式碼，所以整合介面無法達到程式碼的複用。這意味著無論何時需要修改某個行為，必須得往下追蹤並在每一個定義此行為的類中修改它，可能會造成新的錯誤。

策略模式方法

• 把會變化的部分取出並封裝起來，好讓其他部分不受到影響

• 以下的用詞【介面】既可以指java中的interface，也可以指abstract class，只是一個概念性介面

• 如果每次新的需求依賴，都會使某些方面的程式碼發生變化，那麼就可以確定，這部分的程式碼需要被抽出來，和其他穩定的程式碼有所區分

  

將變化的程式碼抽取出來

將經常變化的程式碼，在本例中指fly和quack，抽取出來，獨立為兩個介面：FlyBehavior和QuackBehavior

具體每種實現方式，可以由繼承他們的子類來實現，而Duck類中只需要留下呼叫Behavior的介面即可

優點：

• 這樣的設計，可以讓fly和quack的動作被其他的物件複用，因為這些行為已經與Duck類無關了（例如：在可以發出鴨叫的機器中可以呼叫quack的動作，但是機器不是Duck類）
• 我們可以新增一些行為，不會影響到已有的類，以及使用現有行為的類

現在的Duck類

• 將Duck類中經常變化的行為抽象為一個介面，即flyBehavior和quackBehavior

• 用perform行為來替代原來的行為，即performQuack和performFly替代原來的quack和fly

• 每個子類例項化時，都可以指定該子類對應的行為

  

• 也可以為子類預留setter方法，從而在執行中改變其行為方式

  

  在執行過程中，子類可以動態的呼叫setter方法來改變其行為方式

  

總覽UML圖

設計原則

• 1. 找出應用中可能需要變化之處，把他們獨立出來，不要和那些不需要變化的程式碼混在一起
• 2. 針對介面程式設計，而不是針對實現程式設計
• 3. 多用組合，少用繼承

策略模式

• Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it

  翻譯：策略模式定義了演算法族，分別封裝起來，讓他們之間可以互相替換，此模式讓演算法的變化獨立於使用演算法的客戶。

• Use the Strategy pattern when

  • many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors.

  • you need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms.

  • an algorithm uses data that clients shouldn’t know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures.

  • a class defines many behaviors, and these appearas multiple conditional statements in its operations.
    Instead of many conditionals, move related conditional branches into their own Strategy class.

  翻譯：當出現以下情況時可以使用策略模式：

  • 許多相關類僅在它們的行為上有所不同。策略提供了一種方法來配置具有多種行為之一的類。

  • 你需要一個演算法的不同變體。例如，您可以定義反映不同空間/時間權衡的演算法。當這些變體被實現為演算法的類層次結構時，可以使用策略。

  • 演算法使用客戶端不應該知道的資料。使用Strategy模式可以避免暴露覆雜的、特定於演算法的資料結構。

  • 一個類定義了許多行為，這些行為在它的操作中表現為多個條件語句。將相關的條件分支移動到它們自己的策略類中，而不是使用許多條件語句。

• Consequences

  • Families of related algorithms. Hierarchies of Strategy classes define a family of algorithms or behaviors for contexts to reuse. Inheritance can help factor out common functionality of the algorithms.
  • An alternative to subclassing.
  • Strategies eliminate conditional statements.
  • A choice of implementations. Strategies can provide different implementations of the same behavior. The client can choose among strategies with different time and space trade-offs.
  • Clients must be aware of different Strategies. The pattern has a potential drawback in that a client must understand how Strategies differ before it can select the appropriate one. Clients might be exposed to implementation issues.
  • Communication overhead between Strategy and Context.
  • Increased number of objects.

  翻譯：使用策略模式的影響：

  • 相關演算法族。策略類的層次結構定義了一系列要重用的上下文的演算法或行為。繼承可以幫助提取出演算法的常見功能。
  • 子類化的替代方法。
  • 策略消除了條件語句。
  • 實現的選擇。策略可以為相同的行為提供不同的實現。客戶可以選擇不同的時間和空間權衡策略。
  • 客戶必須瞭解不同的策略。該模式有一個潛在的缺點，即客戶必須瞭解策略之間的差異，然後才能選擇合適的策略。客戶端可能會遇到實現問題。
  • 策略和上下文之間的溝通開銷。
  • 增加的物件數量。