JAVA設計模式詳解（一）----------策略模式

策略模式，顧名思義就是設計一個策略算法，然后與對象拆分開來將其單獨封裝到一系列策略類中，並且它們之間可以相互替換。首先LZ舉一個例子為大家引出這一個模式。

例子：某公司的中秋節獎勵制度為每個員工發放200元，現在我們設計一個員工基類，

public class Staff { public void payOff(){ System.out.println("發工資200"); } }

 

　　然后讓公司各個職位繼承它。（普通員工GeneralStaff  項目經理ProjectManager,部門經理DivisionManager）

現在，公司高管突然下了一個決定，公司開始實施按職位發放節日獎勵，除了每個人發放的200元獎勵外，項目經理還將獲得糖果，而部門經理講獲得月餅。這時，你可能會想在staff中添加一個發獎勵方法，然后子類分別進行重寫

//普通員工GeneralStaff 項目經理ProjectManager,部門經理DivisionManager
 class GeneralStaff extends Staff{ @Override public void grantReward() { System.out.println("什么都不發"); } } class ProjectManager extends Staff{ @Override public void grantReward() { System.out.println("發糖"); } } class DivisionManager extends Staff{ @Override public void grantReward() { System.out.println("發月餅"); } }

 

但是，這樣做會導致重復代碼量增多，而且業務邏輯過於耦合。那么我們怎樣做可以消除這些問題呢？這時我們應該想到了：接口。我們把凡是各不相同的東西抽出來，封裝到一個獨立的接口里，然后分別寫出一系列的實現類去完成算法，

interface GrantReward{ public void grantReward(); } class GrantSuger implements GrantReward{ @Override public void grantReward() { System.out.println("發糖"); } } class GrantMoonCake implements GrantReward{ @Override public void grantReward() { System.out.println("發月餅"); } } class GrantNone implements GrantReward{ @Override public void grantReward() { System.out.println("什么都不發"); } }

 

，而在Staff基類中增加此接口的引用，並將發放獎勵的算法交由接口的實現類來完成，而對算法的選擇則交由子類去做，注意這里我們提供set方法，而不是提供構造器

public abstract class Staff { private GrantReward grantReward; public void payOff(){ System.out.println("發工資200"); } public void grantReward(){ grantReward.grantReward(); } public void setGrantReward(GrantReward grantReward) { this.grantReward = grantReward; } }

這樣我們的子類繼承后，只需要選擇實現類來實例化grantReward即可

//普通員工GeneralStaff 項目經理ProjectManager,部門經理DivisionManager
 class GeneralStaff extends Staff{ public GeneralStaff(){ this.setGrantReward(new GrantNone()); } } class ProjectManager extends Staff{ public ProjectManager(){ this.setGrantReward(new GrantSuger()); } } class DivisionManager extends Staff{ public DivisionManager(){ this.setGrantReward(new GrantMoonCake()); } }

我們寫一個測試類來看看結果如何：

    public static void main(String[] args) {  2         GeneralStaff generalStaff = new GeneralStaff();  3         ProjectManager projectManager = new ProjectManager();  4         DivisionManager divisionManager = new DivisionManager();  5         generalStaff.grantReward();//普通員工
        projectManager.grantReward();//項目經理
        divisionManager.grantReward();//部門經理
        generalStaff.setGrantReward(new GrantMoonCake());  9  generalStaff.grantReward(); 10     }

 

第八行中，我們在行為上動態的更改了一下接口的實現類，發現結果也因此而改變，普通員工也是有月餅的！ =。=

那么這樣設計有什么好處呢？我們來看，這樣的設計可以讓發放月餅和糖的動作被其他對象復用，因為這些行為已經與員工類無關了，而我們可以新增一些行為，不會影響到既有的行為類，也不會影響“使用”到發這些獎勵的行為的員工類。而上面我們之所以不用構造器卻改用set方法，目的是我們不對具體實現編程，而是在運行時可以輕易地改變它。這里我們發現，代碼由“是一個”變成了“有一個”，“有一個”即為組合，這里我們可以得到一個設計原則：多用組合，少用繼承。如你所見，使用組合建立系統具有很大的彈性，不僅可將算法封裝成類，更可以在運行時動態地改變行為，只要組合的行為對象符合正確的接口標准即可。

沒錯，這就是LZ今天要說的策略模式。現在，我們來詳細分析一下策略模式的結構，這個結構相信在有了LZ之前的一個小例子后各位已經很容易能夠看懂。：

 

組成

環境類(Context):用一個ConcreteStrategy對象來配置。維護一個對Strategy對象的引用。可定義一個接口來讓Strategy訪問它的數據，在上一個例子中相當於Staff。

抽象策略類(Strategy):定義所有支持的算法的公共接口。 Context使用這個接口來調用某ConcreteStrategy定義的算法，在上一個例子中相當於GrantReward。

具體策略類(ConcreteStrategy):以Strategy接口實現某具體算法，在上一個例子中相當於GrantSuger，GrantMoonCake，GrantNone。

 

適用情況

許多相關的類僅僅是行為有異。 “策略”提供了一種用多個行為中的一個行為來配置一個類的方法。即一個系統需要動態地在幾種算法中選擇一種。

當一個應用程序需要實現一種特定的服務或者功能，而且該程序有多種實現方式時使用。

一個類定義了多種行為 , 並且這些行為在這個類的操作中以多個條件語句的形式出現。將相關的條件分支移入它們各自的Strategy類中以代替這些條件語句。

 

分析：LZ認為，當有很多可相互替換的算法的時候，我們就可以使用策略模式將這些算法封裝到一系列的策略類里，它把算法的責任和算法本身分割開，委派給不同的對象管理，並讓我們本依賴於算法的類轉而依賴於抽象的算法接口，這樣可以徹底消除類與具體算法之間的耦合，而此時我們可以很方便的改變算法。

針對接口編程，關鍵就在多態，利用多態，程序可以針對基類型編程，執行時會根據實際狀況執行到真正的行為，不會被綁死在基類型的行為上，“針對基類型編程”這句話，更明確的說就是“變量的聲明類型應該是基類型，通常是一個抽象類或者是一個接口，如此，只要是具體實現此基類型的類所產生的對象，都可以指定給這個變量。這也意味着，聲明類時不用理會以后執行時的真正對象類型！”

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不應在各次調用之間維護狀態。

至此，策略模式便已講完，下節預告：觀察者模式。