23種設(shè)計模式（11）java策略模式

更新時間：2017年11月21日 11:41:59 作者：阿木俠

這篇文章主要為大家詳細(xì)介紹了23種設(shè)計模式之java策略模式，具有一定的參考價值，感興趣的小伙伴們可以參考一下

23種設(shè)計模式第四篇：java策略模式

定義：定義一組算法，將每個算法都封裝起來，并且使他們之間可以互換。

類型：行為類模式

類圖：

        策略模式是對算法的封裝，把一系列的算法分別封裝到對應(yīng)的類中，并且這些類實現(xiàn)相同的接口，相互之間可以替換。在前面說過的行為類模式中，有一種模式也是關(guān)注對算法的封裝——模版方法模式。
        對照類圖可以看到，策略模式與模版方法模式的區(qū)別僅僅是多了一個單獨的封裝類Context，它與模版方法模式的區(qū)別在于：在模版方法模式中，調(diào)用算法的主體在抽象的父類中，而在策略模式中，調(diào)用算法的主體則是封裝到了封裝類Context中，抽象策略Strategy一般是一個接口，目的只是為了定義規(guī)范，里面一般不包含邏輯。
        其實，這只是通用實現(xiàn)，而在實際編程中，因為各個具體策略實現(xiàn)類之間難免存在一些相同的邏輯，為了避免重復(fù)的代碼，我們常常使用抽象類來擔(dān)任Strategy的角色，在里面封裝公共的代碼，因此，在很多應(yīng)用的場景中，在策略模式中一般會看到模版方法模式的影子。

策略模式的結(jié)構(gòu)

封裝類：也叫上下文，對策略進(jìn)行二次封裝，目的是避免高層模塊對策略的直接調(diào)用。
抽象策略：通常情況下為一個接口，當(dāng)各個實現(xiàn)類中存在著重復(fù)的邏輯時，則使用抽象類來封裝這部分公共的代碼，此時，策略模式看上去更像是模版方法模式。
具體策略：具體策略角色通常由一組封裝了算法的類來擔(dān)任，這些類之間可以根據(jù)需要自由替換。

策略模式代碼實現(xiàn)

interface IStrategy { 
  public void doSomething(); 
 } 
 class ConcreteStrategy1 implements IStrategy { 
  public void doSomething() { 
   System.out.println("具體策略1"); 
  } 
 } 
 class ConcreteStrategy2 implements IStrategy { 
  public void doSomething() { 
   System.out.println("具體策略2"); 
  } 
 } 
 class Context { 
  private IStrategy strategy; 
   
  public Context(IStrategy strategy){ 
   this.strategy = strategy; 
  } 
   
  public void execute(){ 
   strategy.doSomething(); 
  } 
 } 
  
 public class Client { 
  public static void main(String[] args){ 
   Context context; 
   System.out.println("-----執(zhí)行策略1-----"); 
   context = new Context(new ConcreteStrategy1()); 
   context.execute(); 
  
   System.out.println("-----執(zhí)行策略2-----"); 
   context = new Context(new ConcreteStrategy2()); 
   context.execute(); 
  } 
 }

策略模式的優(yōu)缺點

策略模式的主要優(yōu)點有：

策略類之間可以自由切換，由于策略類實現(xiàn)自同一個抽象，所以他們之間可以自由切換。
易于擴(kuò)展，增加一個新的策略對策略模式來說非常容易，基本上可以在不改變原有代碼的基礎(chǔ)上進(jìn)行擴(kuò)展。
避免使用多重條件，如果不使用策略模式，對于所有的算法，必須使用條件語句進(jìn)行連接，通過條件判斷來決定使用哪一種算法，在上一篇文章中我們已經(jīng)提到，使用多重條件判斷是非常不容易維護(hù)的。

策略模式的缺點主要有兩個：

維護(hù)各個策略類會給開發(fā)帶來額外開銷，可能大家在這方面都有經(jīng)驗：一般來說，策略類的數(shù)量超過5個，就比較令人頭疼了。
必須對客戶端（調(diào)用者）暴露所有的策略類，因為使用哪種策略是由客戶端來決定的，因此，客戶端應(yīng)該知道有什么策略，并且了解各種策略之間的區(qū)別，否則，后果很嚴(yán)重。例如，有一個排序算法的策略模式，提供了快速排序、冒泡排序、選擇排序這三種算法，客戶端在使用這些算法之前，是不是先要明白這三種算法的適用情況？再比如，客戶端要使用一個容器，有鏈表實現(xiàn)的，也有數(shù)組實現(xiàn)的，客戶端是不是也要明白鏈表和數(shù)組有什么區(qū)別？就這一點來說是有悖于迪米特法則的。

適用場景

做面向?qū)ο笤O(shè)計的，對策略模式一定很熟悉，因為它實質(zhì)上就是面向?qū)ο笾械睦^承和多態(tài)，在看完策略模式的通用代碼后，我想，即使之前從來沒有聽說過策略模式，在開發(fā)過程中也一定使用過它吧？至少在在以下兩種情況下，大家可以考慮使用策略模式：