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

策略模式，顧名思義就是設計一個策略演算法，然後與對象拆分開來將其單獨封裝到一系列策略類中，並且它們之間可以相互替換。首先LZ舉一個例子為大家引出這一個模式。例子：某公司的中秋節獎勵制度為每個員工發放200元，現在我們設計一個員工基類，然後讓公司各個職位繼承它。（普通員工GeneralStaff 項 ...

策略模式，顧名思義就是設計一個策略演算法，然後與對象拆分開來將其單獨封裝到一系列策略類中，並且它們之間可以相互替換。首先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());
     }
}

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

 1     public static void main(String[] args) {
 2         GeneralStaff generalStaff = new GeneralStaff();
 3         ProjectManager projectManager = new ProjectManager();
 4         DivisionManager divisionManager = new DivisionManager();
 5         generalStaff.grantReward();//普通員工
 6         projectManager.grantReward();//項目經理
 7         divisionManager.grantReward();//部門經理
 8         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不應在各次調用之間維護狀態。

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