1 意圖
定義一系列的算法，把它們一個個封裝起來，并且使它們可相互替換。本模式使得算法可獨立于使用它的客戶而變化。
2 別名
政策（Policy）
3 動機
有許多算法可對一個正文流進行分析。將這些算法硬編進使用它們的類中是不可取的，其原因如下：
- 需要換行功能的客戶程序如果直接包含換行算法代碼的話將會變得復雜，這使得客戶程序龐大并且難以維護, 尤其當其需要支持多種換行算法時問題會更加嚴重。
- 不同的時候需要不同的算法，我們不想支持我們并不使用的換行算法。
-
當換行功能是客戶程序的一個難以分割的成分時 ,增加新的換行算法或改變現有算法將十分困難。
我們可以定義一些類來封裝不同的換行算法，從而避免這些問題。一個以這種方法封裝的算法稱為一個策略（Strategy），如下圖：
image.png
假設一個Composition類負責維護和更新一個正文瀏覽程序中顯示的正文換行。換行策略不是 Composition類實現的，而是由抽象的Composition類的子類各自獨立地實現的。Composition各個子類實現不同的換行策略：
- SimpleComposition實現一個簡單的策略，它一次決定一個換行位置。
- TeXComposition實現查找換行位置的TEX算法。這個策略盡量全局地優化換行，也就是一次處理一段文字的換行；
- ArrayCompositor實現一個策略, 該策略使得每一行都含有一個固定數目的項。例如 , 用于對一系列的圖標進行分行。
Composition維護對Compositor對象的一個引用。一旦Composition重新格式化它的正文，它就將這個職責轉發給它的Compositor對象。Compositor的客戶指定應該使用哪一種Compositor的方式是直接將它想要的Compositor裝入Composition中。
4 適用性
當存在以下情況時使用Strategy模式：
- 許多相關的類僅僅是行為有異。“策略”提供了一種用多個行為中的一個行為來配置一個類的方法。
- 需要使用一個算法的不同變體。例如，你可能會定義一些反映不同的空間 /時間權衡的算法。當這些變體實現為一個算法的類層次時 [ H O 8 7 ] ,可以使用策略模式。
- 算法使用客戶不應該知道的數據。可使用策略模式以避免暴露復雜的、與算法相關的數據結構。
- 一個類定義了多種行為 , 并且這些行為在這個類的操作中以多個條件語句的形式出現。將相關的條件分支移入它們各自的 S t r a t e g y類中以代替這些條件語句。
5 結構
image.png
參與者
- Strategy（策略，如Compositor）
——定義所有支持的算法的公共接口。 Context使用這個接口來調用某ConcreteStrategy定義的算法； - ConcreteStrategy（具體策略，如SimpleCompositor，TeXCompositor，ArrayCompositor）
——以Strategy接口實現某具體算法 - Context（上下文，如Composition）
——用一個ConcreteStrategy對象來配置
——維護一個對Strategy對象的引用
——可定義一個接口來讓Strategy訪問它的數據
7 協作
- Strategy和Context相互作用以實現選定的算法。當算法被調用時 , Context可以將該算法所需要的所有數據都傳遞給該Strategy。或者，Context可以將自身作為一個參數傳遞給Strategy操作。這就讓Strategy在需要時可以回調Context。
- Context將它的客戶的請求轉發給它的Strategy。客戶通常創建并傳遞一個ConcreteStrategy對象給該Context；這樣，客戶僅與Context交互。通常有一系列的ConcreteStrategy類可供客戶從中選擇。
8 效果
Strategy模式有下面的一些優點和缺點：
- 1 相關算法系列：Strategy類層次為Context定義了一系列的可供重用的算法或行為。繼承有助于析取出這些算法中的公共功能。
- 2 一個替代繼承的方法：繼承提供了另一種支持多種算法或行為的方法。你可以直接生成一個Context類的子類，從而給它以不同的行為。但這會將行為硬行編制到Context中，而將算法的實現與Context的實現混合起來 ,從而使Context難以理解、難以維護和難以擴展，而且還不能動態地改變算法。最后你得到一堆相關的類 , 它們之間的唯一差別是它們所使用的算法或行為。將算法封裝在獨立的Strategy類中使得你可以獨立于其Context改變它，使它易于切換、易于理解、易于擴展。
- 3 消除了一些條件語句：Strategy模式提供了用條件語句選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類中時 , 很難避免使用條件語句來選擇合適的行為。將行為封裝在一個個獨立的Strategy類中消除了這些條件語句。
- 4 實現的選擇：Strategy模式可以提供相同行為的不同實現。客戶可以根據不同時間 /空間權衡取舍要求從不同策略中進行選擇。
- 5 客戶必須了解不同的Strategy：本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實現問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。
- 6 Strategy和Context之間的通信開銷；
- 7 增加了對象的數目
9 實現
考慮下面的實現問題:
- 1 定義 Strategy和Context接口： Strategy和Context接口必須使得ConcreteStrategy能夠有效的訪問它所需要的Context中的任何數據, 反之亦然。一種辦法是讓Context將數據放在參數中傳遞給Strategy操作 — 也就是說, 將數據發送給Strategy。這使得Strategy和Context解耦。但另一方面，Context可能發送一些Strategy不需要的數據；
另一種辦法是讓Context將自身作為一個參數傳遞給Strategy, 該Strategy再顯式地向該Context請求數據。或者，Strategy可以存儲對它的Context的一個引用，這樣根本不再需要傳遞任何東西。在這兩種情況下，Strategy都可以請求到它所需要的數據。但現在Context必須對它的數據定義一個更為精細的接口，這將Strategy和Context更緊密地耦合在一起； - 2 將Strategy作為模板參數 在C + +中，可利用模板機制用一個Strategy來配置一個類。然而這種技術僅當下面條件滿足時才可以使用 (1) 可以在編譯時選擇Strategy (2) 它不需在運行時改變。在這種情況下，要被配置的類（如，Context）被定義為以一個Strategy類作為一個參數的模板類。
- 3 使Strategy對象成為可選的：如果即使在不使用額外的 Strategy對象的情況下，Context也還有意義的話，那么它還可以被簡化。Context在訪問某Strategy前先檢查它是否存在，如果有，那么就使用它；如果沒有，那么Context執行缺省的行為。這種方法的好處是客戶根本不需要處理Strategy對象，除非它們不喜歡缺省的行為。
