Java中避免if-else-if：策略模式
本文僅僅為入門，高手勿噴。
實(shí)際工作中，我們總會(huì)遇到類似如下的需求：
某支付系統(tǒng)接入以下幾種商戶進(jìn)行充值：易寶網(wǎng)易，快線網(wǎng)銀，19pay手機(jī)支付，支付寶支付，駿網(wǎng)一卡通，由于每家充值系統(tǒng)的結(jié)算比例不一樣，而且 同一家商戶的不同充值方式也有所不同，具體系統(tǒng)情況比較復(fù)雜，像支付寶既有支付寶賬號(hào)支付和支付寶網(wǎng)銀支付等這些暫時(shí)不考慮，為了講述策略模式這里簡(jiǎn)單描 述，假如分為四種，手機(jī)支付，網(wǎng)銀支付，商戶賬號(hào)支付和點(diǎn)卡支付。因?yàn)闆]個(gè)支付結(jié)算比例不同，所以對(duì)手續(xù)費(fèi)低的做一些優(yōu)惠活動(dòng)，盡可能讓用戶使用手續(xù)費(fèi)低 的支付方式來充值，這樣降低渠道費(fèi)用，增加收入，具體優(yōu)惠政策如下：
網(wǎng)銀充值，8.5折
商戶充值，9折
手機(jī)充值，沒有優(yōu)惠
點(diǎn)卡充值，收取1%的渠道費(fèi)
作為一個(gè)新手的代碼基本如下：
public class Example {public Double calRecharge(Double charge ,RechargeTypeEnum type ){if(type.equals(RechargeTypeEnum.E_BANK)){return charge*0.85;}else if(type.equals(RechargeTypeEnum.BUSI_ACCOUNTS)){return charge*0.90;}else if(type.equals(RechargeTypeEnum.MOBILE)){return charge;}else if(type.equals(RechargeTypeEnum.CARD_RECHARGE)){return charge+charge*0.01;}else{return null;}}} public enum RechargeTypeEnum {E_BANK(1, "網(wǎng)銀"),BUSI_ACCOUNTS(2, "商戶賬號(hào)"),MOBILE(3,"手機(jī)卡充值"),CARD_RECHARGE(4,"充值卡");private int value;private String description;private RechargeTypeEnum(int value, String description) {this.value = value;this.description = description;}public int value() {return value;}public String description() {return description;}public static RechargeTypeEnum valueOf(int value) {for(RechargeTypeEnum type : RechargeTypeEnum.values()) {if(type.value() == value) {return type;}}return E_BANK;} }以上代碼雖然實(shí)現(xiàn)了基本功能，但是四種計(jì)算方式都在一個(gè)方法內(nèi)部，如果優(yōu)惠模式又增加了幾十種，代碼會(huì)變成什么樣？你是否愿意來維護(hù)和擴(kuò)展這樣的代碼？此時(shí)有的同學(xué)或許會(huì)說，我用switch-case來實(shí)現(xiàn)：
public class Example {public Double calRecharge(Double charge ,RechargeTypeEnum type ){switch(type){case RechargeTypeEnum.E_BANK:return charge*0.85;case RechargeTypeEnum.BUSI_ACCOUNTS:return charge*0.90;case RechargeTypeEnum.MOBILE:return charge; case RechargeTypeEnum.CARD_RECHARGE:retrun charge+charge*0.01;default：return null;}}}這段代碼在簡(jiǎn)潔性確實(shí)要比if-else簡(jiǎn)潔一些，但實(shí)際上是換湯不換藥，并沒有從本質(zhì)上解決問題。
我們使用if-else事實(shí)上也是為了重用，但這只是面向過程的重用，程序員只看到代碼重用，因?yàn)樗吹絠f-else幾種情況下大部分代碼都是重復(fù)的，只有個(gè)別不同，因此使用if-else可以避免重復(fù)代碼，并且認(rèn)為這是模板Template模式。我們會(huì)從代碼運(yùn)行順序來看待代碼，這種思維類似水管或者串行電路，水沿著水管流動(dòng)（代碼運(yùn)行次序），當(dāng)遇到幾個(gè)分管（子管），就分到這幾個(gè)分管子在流動(dòng)，這里就相當(dāng)于碰到代碼的if-else處了。這樣的壞處就是，一旦業(yè)務(wù)發(fā)生了變化將給我們維護(hù)工作帶來極大的困難。
那么有沒有更好的實(shí)現(xiàn)方式呢？當(dāng)然有，我們可以通過工廠模式或者策略模式避免如上的面向過程的重用。而本文將要介紹的是 策略模式
策略模式（Policy)
定義一系列的算法,把每一個(gè)算法封裝起來,并且使它們可相互替換。本模式使得算法可獨(dú)立于使用它的客戶而變化。也稱為政策模式(Policy)。（Definea family of algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients that use it.）UML圖如下
sss1.jpg由上圖可看出策略模式由以下角色構(gòu)成：
- 抽象策略角色： 策略類，通常由一個(gè)接口或者抽象類實(shí)現(xiàn)。
- 具體策略角色：包裝了相關(guān)的算法和行為。
- 環(huán)境角色：持有一個(gè)策略類的引用，最終給客戶端調(diào)用。
策略模式讓算法獨(dú)立于使用它的客戶而獨(dú)立變化。策略模式重點(diǎn)是封裝不同的算法和行為，不同的場(chǎng)景下可以相互替換。策略模式是開閉原則的體現(xiàn)，開閉原則講的是一個(gè)軟件實(shí)體應(yīng)該對(duì)擴(kuò)展開放對(duì)修改關(guān) 閉。策略模式在新的策略增加時(shí)，不會(huì)影響其他類的修改，增加了擴(kuò)展性，也就是對(duì)擴(kuò)展是開放的；對(duì)于場(chǎng)景來說，只依賴于抽象，而不依賴于具體實(shí)現(xiàn)，所以對(duì)修改是關(guān)閉的。策略模式的認(rèn)識(shí)可以借助《java與模式》一書中寫到諸葛亮的錦囊妙計(jì)來學(xué)習(xí)，在不同的場(chǎng)景下趙云打開不同的錦囊，便化險(xiǎn)為夷，錦囊便是抽象策略，具體的錦囊里面的計(jì)策便是具體的策略角色，場(chǎng)景就是趙云，變化的處境選擇具體策略的條件。
Strategy模式有下面的一些優(yōu)點(diǎn)：
Strategy模式缺點(diǎn):
1)客戶端必須知道所有的策略類，并自行決定使用哪一個(gè)策略類: 本模式有一個(gè)潛在的缺點(diǎn)，就是一個(gè)客戶要選擇一個(gè)合適的Strategy就必須知道這些Strategy到底有何不同。此時(shí)可能不得不向客戶暴露具體的實(shí)現(xiàn)問題。因此僅當(dāng)這些不同行為變體與客戶相關(guān)的行為時(shí) , 才需要使用Strategy模式。
2 ) Strategy和Context之間的通信開銷 ：無論各個(gè)ConcreteStrategy實(shí)現(xiàn)的算法是簡(jiǎn)單還是復(fù)雜, 它們都共享Strategy定義的接口。因此很可能某些 ConcreteStrategy不會(huì)都用到所有通過這個(gè)接口傳遞給它們的信息；簡(jiǎn)單的 ConcreteStrategy可能不使用其中的任何信息！這就意味著有時(shí)Context會(huì)創(chuàng)建和初始化一些永遠(yuǎn)不會(huì)用到的參數(shù)。如果存在這樣問題 , 那么將需要在Strategy和Context之間更進(jìn)行緊密的耦合。
3 )策略模式將造成產(chǎn)生很多策略類：可以通過使用享元模式在一定程度上減少對(duì)象的數(shù)量。 增加了對(duì)象的數(shù)目 Strategy增加了一個(gè)應(yīng)用中的對(duì)象的數(shù)目。有時(shí)你可以將 Strategy實(shí)現(xiàn)為可供各Context共享的無狀態(tài)的對(duì)象來減少這一開銷。任何其余的狀態(tài)都由 Context維護(hù)。Context在每一次對(duì)Strategy對(duì)象的請(qǐng)求中都將這個(gè)狀態(tài)傳遞過去。共享的 Strategy不應(yīng)在各次調(diào)用之間維護(hù)狀態(tài)。
策略模式在實(shí)際工作中也很常用，在博客你還在用if-else嗎有過很好的闡述，策略模式不僅是繼承的代替方案，還能很好地解決if-else問題。下面結(jié)合本文之前的例子來說明一下如何使用策略模式。
策略模式下的UML圖如下:
創(chuàng)建抽象策略角色Strategy：
public interface Strategy {public Double calRecharge(Double charge ,RechargeTypeEnum type ); }根據(jù)需求，分別實(shí)現(xiàn)Strategy即具體策略角色：
public class EBankStrategy implements Strategy{@Overridepublic Double calRecharge(Double charge, RechargeTypeEnum type) {return charge*0.85;} public class BusiAcctStrategy implements Strategy{@Overridepublic Double calRecharge(Double charge, RechargeTypeEnum type) {return charge*0.90;}} public class MobileStrategy implements Strategy {@Overridepublic Double calRecharge(Double charge, RechargeTypeEnum type) {return charge;}} public class CardStrategy implements Strategy{@Overridepublic Double calRecharge(Double charge, RechargeTypeEnum type) {return charge+charge*0.01;}}創(chuàng)建環(huán)境角色Context:
public class Context {private Strategy strategy;public Double calRecharge(Double charge, Integer type) {strategy = StrategyFactory.getInstance().creator(type);return strategy.calRecharge(charge, RechargeTypeEnum.valueOf(type));}public Strategy getStrategy() {return strategy;}public void setStrategy(Strategy strategy) {this.strategy = strategy;}}StrategyFactory工廠,負(fù)責(zé)Strategy實(shí)例的創(chuàng)建：
public class StrategyFactory {private static StrategyFactory factory = new StrategyFactory();private StrategyFactory(){}private static Map strategyMap = new HashMap<>();static{strategyMap.put(RechargeTypeEnum.E_BANK.value(), new EBankStrategy());strategyMap.put(RechargeTypeEnum.BUSI_ACCOUNTS.value(), new BusiAcctStrategy());strategyMap.put(RechargeTypeEnum.MOBILE.value(), new MobileStrategy());strategyMap.put(RechargeTypeEnum.CARD_RECHARGE.value(), new CardStrategy());}public Strategy creator(Integer type){return strategyMap.get(type);}public static StrategyFactory getInstance(){return factory;} }開始測(cè)試：
public class Client {public static void main(String[] args) {Context context = new Context();// 網(wǎng)銀充值100 需要付多少Double money = context.calRecharge(100D,RechargeTypeEnum.E_BANK.value());System.out.println(money);// 商戶賬戶充值100 需要付多少Double money2 = context.calRecharge(100D,RechargeTypeEnum.BUSI_ACCOUNTS.value());System.out.println(money2);// 手機(jī)充值100 需要付多少Double money3 = context.calRecharge(100D,RechargeTypeEnum.MOBILE.value());System.out.println(money3);// 充值卡充值100 需要付多少Double money4 = context.calRecharge(100D,RechargeTypeEnum.CARD_RECHARGE.value());System.out.println(money4);}}運(yùn)行結(jié)果：
85.0
90.0
100.0
101.0
從上面類圖和代碼可以看出，策略模式把具體的算法封裝到了具體策略角色內(nèi)部，增強(qiáng)了可擴(kuò)展性，隱蔽了實(shí)現(xiàn)細(xì)節(jié)；它替代繼承來實(shí)現(xiàn)，避免了if- else這種不易維護(hù)的條件語句。當(dāng)然我們也可以看到，策略模式由于獨(dú)立策略實(shí)現(xiàn)，使得系統(tǒng)內(nèi)增加了很多策略類；對(duì)客戶端來說必須知道兜友哪些具體策略， 而且需要知道選擇具體策略的條件。
總結(jié)
凡事具有兩面性，策略模式也不例外，下面簡(jiǎn)單列舉一下策略模式的優(yōu)缺點(diǎn)。
優(yōu)點(diǎn)：
缺點(diǎn):
2 . Strategy和Context之間的通信開銷 ：無論各個(gè)ConcreteStrategy實(shí)現(xiàn)的算法是簡(jiǎn)單還是復(fù)雜, 它們都共享Strategy定義的接口。因此很可能某些 ConcreteStrategy不會(huì)都用到所有通過這個(gè)接口傳遞給它們的信息；簡(jiǎn)單的 ConcreteStrategy可能不使用其中的任何信息！這就意味著有時(shí)Context會(huì)創(chuàng)建和初始化一些永遠(yuǎn)不會(huì)用到的參數(shù)。如果存在這樣問題 , 那么將需要在Strategy和Context之間更進(jìn)行緊密的耦合。
3 . 策略模式將造成產(chǎn)生很多策略類：可以通過使用享元模式在一定程度上減少對(duì)象的數(shù)量。 增加了對(duì)象的數(shù)目 Strategy增加了一個(gè)應(yīng)用中的對(duì)象的數(shù)目。有時(shí)你可以將 Strategy實(shí)現(xiàn)為可供各Context共享的無狀態(tài)的對(duì)象來減少這一開銷。任何其余的狀態(tài)都由 Context維護(hù)。Context在每一次對(duì)Strategy對(duì)象的請(qǐng)求中都將這個(gè)狀態(tài)傳遞過去。共享的 Strategy不應(yīng)在各次調(diào)用之間維護(hù)狀態(tài)。
最后，是否應(yīng)該重構(gòu)一下你的代碼了？
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)總結(jié)
以上是生活随笔為你收集整理的Java中避免if-else-if：策略模式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Google play billing(
- 下一篇： 华为nova好不好 先看图