iOS設計模式 - (4)策略模式

標籤：style   blog   http   io   color   os   ar   使用   sp   

理論部分，參考博文：http://blog.csdn.net/hguisu/article/details/7558249

1.概述 

在軟體開發中也常常遇到類似的情況，實現某一個功能有多種演算法或者策略，我們可以根據環境或者條件的不同選擇不同的演算法或者策略來完成該功能。如尋找、排序等，一種常用的方法是寫入程式碼(Hard Coding)在一個類中，如需要提供多種尋找演算法，可以將這些演算法寫到一個類中，在該類中提供多個方法，每一個方法對應一個具體的尋找演算法；當然也可以將這些尋找演算法封裝在一個統一的方法中，通過if…else…或者case等條件判斷語句來進行選擇。這兩種實現方法我們都可以稱之為寫入程式碼，如果需要增加一種新的尋找演算法，需要修改封裝演算法類的原始碼；更換尋找演算法，也需要修改用戶端調用代碼。在這個演算法類中封裝了大量尋找演算法，該類代碼將較複雜，維護較為困難。如果我們將這些策略包含在用戶端，這種做法更不可取，將導致用戶端程式龐大而且難以維護，如果存在大量可供選擇的演算法時問題將變得更加嚴重。

例子1：一個菜單功能能夠根據使用者的“皮膚”喜好設定來決定是否採用水平的還是垂直的排列形式。同事可以靈活增加菜單那的顯示樣式。

例子2：出行旅遊：我們可以有幾個策略可以考慮：可以騎單車，汽車，做火車，飛機。每個策略都可以得到相同的結果，但是它們使用了不同的資源。選擇策略的依據是費用，時間，使用工具還有每種方式的方便程度 。

2.問題

如何讓演算法和對象分開來，使得演算法可以獨立於使用它的客戶而變化？

3.解決方案

策略模式：定義一系列的演算法,把每一個演算法封裝起來, 並且使它們可相互替換。本模式使得演算法可獨立於使用它的客戶而變化。也稱為政策模式(Policy)。（Definea family of algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients that use it. ）

策略模式把對象本身和運算規則區分開來，其功能非常強大，因為這個設計模式本身的核心思想就是物件導向編程的多型的思想。

4.適用性

當存在以下情況時使用Strategy模式
1）? 許多相關的類僅僅是行為有異。 “策略”提供了一種用多個行為中的一個行為來配置一個類的方法。即一個系統需要動態地在幾種演算法中選擇一種。
2）? 需要使用一個演算法的不同變體。例如，你可能會定義一些反映不同的空間 /時間權衡的演算法。當這些變體實現為一個演算法的類層次時 ,可以使用原則模式。
3）? 演算法使用客戶不應該知道的資料。可使用原則模式以避免暴露複雜的、與演算法相關的資料結構。
4）? 一個類定義了多種行為 , 並且這些行為在這個類的操作中以多個條件陳述式的形式出現。將相關的條件分支移入它們各自的Strategy類中以代替這些條件陳述式。

5.結構

6.效果

Strategy模式有下面的一些優點：
1) 相關演算法系列 Strategy類層次為Context定義了一系列的可供重用的演算法或行為。 繼承有助於析取出這些演算法中的公用功能。
2) 提供了可以替換繼承關係的辦法： 繼承提供了另一種支援多種演算法或行為的方法。你可以直接產生一個Context類的子類，從而給它以不同的行為。但這會將行為硬行編製到 Context中，而將演算法的實現與Context的實現混合起來,從而使Context難以理解、難以維護和難以擴充，而且還不能動態地改變演算法。最後你得到一堆相關的類 , 它們之間的唯一差別是它們所使用的演算法或行為。 將演算法封裝在獨立的Strategy類中使得你可以獨立於其Context改變它，使它易於切換、易於理解、易於擴充。
3) 消除了一些if else條件陳述式 ：Strategy模式提供了用條件陳述式選擇所需的行為以外的另一種選擇。當不同的行為堆砌在一個類中時 ,很難避免使用條件陳述式來選擇合適的行為。將行為封裝在一個個獨立的Strategy類中消除了這些條件陳述式。含有許多條件陳述式的代碼通常意味著需要使用Strategy模式。
4) 實現的選擇 Strategy模式可以提供相同行為的不同實現。客戶可以根據不同時間 /空間權衡取捨要求從不同策略中進行選擇。

Strategy模式缺點:

1)用戶端必須知道所有的策略類，並自行決定使用哪一個策略類:  本模式有一個潛在的缺點，就是一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實現問題。因此僅當這些不同行為變體與客戶相關的行為時 , 才需要使用Strategy模式。
2 ) Strategy和Context之間的通訊開銷 ：無論各個ConcreteStrategy實現的演算法是簡單還是複雜, 它們都共用Strategy定義的介面。因此很可能某些 ConcreteStrategy不會都用到所有通過這個介面傳遞給它們的資訊；簡單的 ConcreteStrategy可能不使用其中的任何資訊！這就意味著有時Context會建立和初始化一些永遠不會用到的參數。如果存在這樣問題 , 那麼將需要在Strategy和Context之間更進行緊密的耦合。
3 )策略模式將造成產生很多策略類：可以通過使用享元模式在一定程度上減少對象的數量。 增加了對象的數目 Strategy增加了一個應用中的對象的數目。有時你可以將 Strategy實現為可供各Context共用的無狀態的對象來減少這一開銷。任何其餘的狀態都由 Context維護。Context在每一次對Strategy對象的請求中都將這個狀態傳遞過去。共用的 Strategy不應在各次調用之間維護狀態。

7. iOS應用分析

例如，我們在驗證使用者輸入的表單的時候，加入包括電話輸入框的驗證和郵件輸入框的驗證，這兩部分的驗證演算法是不同的，如果把這個演算法看成一個函數，他幾乎有相同的輸入參數和返回參數。我們可以把這個相同的函數可以抽象為基類(InputValidator)的一個方法(bool validateInput(input,error))，然後抽象出兩個具體的策略類：電話驗證類(PhoneValidator)和郵件驗證類(EmailValidator)，他們需要在各自的實現裡面去複寫父類的驗證方法。為了能夠正常的調用到驗證類的驗證方法，我們需要自訂一個UITextField的子類CustomTextField，其中有一個InputValidator類型的引用和一個validate方法，該方法裡面調用InputValidator的驗證方法，然後在textFieldDidEndEditing代理方法裡面調用CustomTextField的validate方法，這樣就不用我們在判斷輸入是否合法的時候通過if else去處理每種邏輯，而且這樣做方便擴充，提高可複用性。

執行個體：排序演算法，NSArray的sortedArrayUsingSelector；經典的鴨子會叫，會飛案例。

8. iOS執行個體下載

這裡提供了一個iOS版本的鴨子工程, 可以參考下

 設計模式-策略模式.zip

iOS設計模式 - (4)策略模式