策略模式——（+簡單工廠模式+反射）

策略模式，需要我們結合簡單工廠模式，更高級地用法可能需要我們掌握Java反射機制。簡單工廠模式我們在最早的時候介紹，我們也談到了一點Java的反射機制。借着學習策略模式的機會，我們順便復習一下簡單工廠模式和反射。

先說說何為策略模式。“策略”我的理解是，對一件事，有不同的方法去做，至於用何種方法取決於我們的選擇。我們同樣借助《大話設計模式》中實現策略模式的例子來做講解。

超市進場做活動，我們現在假設有正常不減價、打折、滿減這三種活動，這正是對“買東西收費”這件事，有三種不同的“方法”，這三種方法其實就是三種不同的算法。我們定義出策略模式：它定義了算法家族，分別封裝起來，讓它們之間可以互相替換，此模式讓算法的變化不會影響到使用算法的客戶。看到這個可能還是一臉茫然，不着急我們一步一步來這句話到底想表達什么意思。

首先，對於正常不減價，我們可以直接計算返回該收取的金額為多少。對於打折的這種情況，我們可能會想到傳遞一個“打多少折”的參數進去，計算返回該收取的金額為多少。對於滿減的這種情況，我們傳遞兩個參數，“返利條件”及“返多少利”，計算返回該收取的金額為多少。那么它們似乎都有一個公共方法，對於應收金額，返回實收金額。我們可以將三種情況抽取為一個接口或抽象類。來試着畫出UML類圖結構。

看到UML的類結構圖，我們其實可以聯想到簡單工廠模式，如果我們就這樣來寫，在客戶端就需要來具體實例化哪一個類。我們不想在客戶端來做出判斷決定來實例化哪一個類，這個時候怎么辦呢——簡單工廠模式可以幫我們實現。客戶端不決定具體實例化哪一個類，而是交由“工廠”來幫我們實例化。所以其實我們首先是實現的一個“簡單工廠模式”。

所以我們上面的UML類結構圖就可以做下修改。

接下來寫出我們的代碼。

package day_20_cash;

/**
 * 收費接口
 * @author turbo
 *
 * 2016年9月20日
 */
public interface CashSuper {
    /**
     * 計算實收的費用
     * @param money 應收金額
     * @return 實收金額
     */
    double acceptCash(double money);
}

package day_20_cash;

/**
 * 正常收費
 * @author turbo
 *
 * 2016年9月20日
 */
public class CashNormal implements CashSuper {

    /* (non-Javadoc)
     * @see day_20_cash.CashSuper#acceptCash(double)
     */
    @Override
    public double acceptCash(double money) {

        return money;
    }

}

package day_20_cash;

/**
 * 打折
 * @author turbo
 *
 * 2016年9月20日
 */
public class CashRebate implements CashSuper {
    private double moneyRebate;
    

    /**
     * @param moneyRebate 折扣率
     */
    public CashRebate(double moneyRebate) {
        this.moneyRebate = moneyRebate;
    }


    /* (non-Javadoc)
     * @see day_20_cash.CashSuper#acceptCash(double)
     */
    @Override
    public double acceptCash(double money) {
        
        return money * (moneyRebate / 10);
    }

}

package day_20_cash;

/**
 * 滿減
 * @author turbo
 *
 * 2016年9月20日
 */
public class CashReturn implements CashSuper {
    private double moneyCondition;    //應收金額
    private double moneyReturn;    //返利金額
    
    public CashReturn(double moneyCondition, double moneyReturn){
        this.moneyCondition = moneyCondition;
        this.moneyReturn = moneyReturn;
    }
    /* (non-Javadoc)
     * @see day_20_cash.CashSuper#acceptCash(double)
     */
    @Override
    public double acceptCash(double money) {
        if (money >= moneyCondition){
            money = money - moneyReturn;
        }
        return money;
    }

}

package day_20_cash;

/**
 * 收費對象生成工廠
 * @author turbo
 *
 * 2016年9月20日
 */
public class CashFactory {
    public static CashSuper createCashAccept(String cashType){
        CashSuper cs = null;
        switch (cashType) {
            case "正常收費" :
                cs = new CashNormal();
                break;
            case "打8折" :
                cs = new CashRebate(8);
                break;
            case "滿300減100" :
                cs = new CashReturn(300, 100);
                break;
            default :
                break;
        }
        
        return cs; 
    }
}

package day_20_cash;

/**
 * 客戶端抽象代碼
 * @author turbo
 *
 * 2016年9月20日
 */
public class Main {

    /**
     * @param args
     */
    public static void main(String[] args) {
        CashSuper cs = CashFactory.createCashAccept("打8折");
        double result = cs.acceptCash(300);
        System.out.println(result);
    }

}

這樣雖然在客戶端中，我們不用關系具體實體化哪一個類，但這同樣也帶來一定的問題，如果我們要打7折呢？我們是否要在工廠類中新增一個case？那滿500減100呢？商場的活動經常在改變，如果真向我們現在所寫的這樣未免有些牽強，我們要不斷地去修改工廠類，不斷地重新編譯重新部署。面對算法的時常變動，我們可以選擇策略模式。

對於策略模式，我們需要引入一個CashContext類，這個類用於維護對Strategy對象的引用。還是太抽象，我們從代碼的角度來看，CashContext是一個什么類。（上面的CashSuper及其實現類不用修改）

package day_20_cash;

/**
 * Context上下文，維護對strategy對象的引用
 * @author turbo
 *
 * 2016年9月21日
 */
public class CashContext {
    CashSuper cs = null;
    public CashContext(CashSuper csuper){
        this.cs = csuper;
    }
    
    public double getResult(double money){
        
        return cs.acceptCash(money);
    }
}

再來看客戶端代碼怎么寫。

package day_20_cash;

/**
 * 客戶端抽象代碼
 * @author turbo
 *
 * 2016年9月20日
 */
public class Main {

    /**
     * @param args
     */
    public static void main(String[] args) {
        CashContext context = null;
        double money = 0.0;
        String strategy = "打8折";
        switch (strategy) {
            case "正常收費" :
                context = new CashContext(new CashNormal());
                break;
            case "打8折" :
                context = new CashContext(new CashRebate(8));
                break;
            case "滿300減100" :
                context = new CashContext(new CashReturn(300, 100));
                break;

            default :
                break;
        }
        
        money = context.getResult(300);
        System.out.println(money);
    }

}

這樣我們就實現了策略模式。

但是，我們又再一次客戶端做了判斷，實際上我們似乎是將switch語句從工廠移到了客戶端，這不又違背我們的初衷回到原點了嗎？那我們是否能將switch“又移到”工廠中去呢？換句話說，策略模式和工廠模式相結合。

我們改進CashContext在其中實現簡單工廠。

package day_20_cash;

/**
 * Context上下文，維護對strategy對象的引用
 * @author turbo
 *
 * 2016年9月21日
 */
public class CashContext {
    CashSuper cs = null;
    public CashContext(String type){
        switch (type) {
            case "正常收費" :
                CashNormal normal = new CashNormal();
                cs = normal;
                break;
            case "滿300減100" :
                CashReturn returnx = new CashReturn(300, 100);
                cs = returnx;
            case "打8折" :
                CashRebate rebate = new CashRebate(8);
                cs = rebate;
            default :
                break;
        }
    }
    
    public double getResult(double money){
        
        return cs.acceptCash(money);
    }
}

客戶端測試代碼：

package day_20_cash;

/**
 * 客戶端抽象代碼
 * @author turbo
 *
 * 2016年9月21日
 */
public class Main {

    /**
     * @param args
     */
    public static void main(String[] args) {
        CashContext context = null;
        double money = 0.0;
        String strategy = "打8折";
        context = new CashContext(strategy);
        money = context.getResult(300);
        System.out.println(money);
    }

}

從代碼角度來看，不就是把switch從Main客戶端類移到了CashContext類嘛，好像根本沒什么用啊。我們用書里的解釋吧，“簡單工廠模式需要讓客戶端認識兩個類，CashSuper和CashFactory，而策略模式與簡單工廠結合的用法，客戶端就只需要認識一個類CashContext就可以了。耦合更加降低。”“我們在客戶端實例化的是CashContext的對象，調用的是CashContext的方法getResult，這使得具體的收費算法徹底地與客戶端分離。連算法的父類CashSuper都不讓客戶端認識了。”

在這里我們要領會“客戶端”帶來的含義是什么，在這里我們就是寫的一個main函數，“客戶端”在編碼過程中，我們可以把它想象理解為調用方。調用方如果引用多個類是不是帶來很大的耦合性？但如果只引用一個類，那是不是只需要維護這個類的引用即可？這也就是我們常說的解耦。

下面我們來實現在最開始提到的使用“反射”來去掉switch判斷語句，可以先自己思考一下試着自己寫出來。這里可以參考一下之前涉及到一點反射的博文，《初識Java反射》，《工廠模式——抽象工廠模式（+反射）》。

修改CashContext類，利用反射消除Switch判斷語句：

package day_20_cash;

import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;

/**
 * Context上下文，維護對strategy對象的引用
 * @author turbo
 *
 * 2016年9月22日
 */
public class CashContext {
    Class<?> clazz = null;
    Object obj = null;
    public CashContext(String className, Class[] paramsType, Object[] parmas){
        try {
            clazz = Class.forName(className);
            Constructor con = clazz.getConstructor(paramsType);
            obj = con.newInstance(parmas);
        } catch (InstantiationException | IllegalAccessException e) {
            e.printStackTrace();
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (IllegalArgumentException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (SecurityException e) {
            e.printStackTrace();
        }
        
    }
    
    public double getResult(double money){
        
        return ((CashSuper)obj).acceptCash(money);
    }
}

修改客戶端測試代碼：

package day_20_cash;

/**
 * 客戶端測試代碼
 * @author turbo
 *
 * 2016年9月22日
 */
public class Main {

    /**
     * @param args
     */
    public static void main(String[] args) {
        CashContext context = null;
        double money = 0.0;
        String type = "day_20_cash.CashRebate";
        Class[] paramTypes = {double.class};    //注意在這里不能使用double的引用類型Double，我猜測是這樣涉及一點自動裝箱和拆箱
        Object[] params = {8.0}; 
        context = new CashContext(type, paramTypes, params);
        money = context.getResult(300);
        System.out.println(money);
    }

}

至於為什么要用到反射來消除switch，在上面兩篇博文中已經有提到過，這里不再敘述。其實在客戶端測試代碼中，我們還可以進一步把代碼寫得再優美一點。