前言

在實(shí)際業(yè)務(wù)代碼中，我們經(jīng)常會(huì)碰到這樣的代碼：

String type = actualService.getRealtype(uid);if(type.equals('typeA')){ // do func A}else if(type.equals('typeB')){ // do func B}else if(type.equals('typeC')){ // do func C}else[ //...}

這種 if-else 或者 switch-case 代碼在每個(gè)分支都會(huì)判斷分支類型，然后執(zhí)行不同的方法獲取結(jié)果，當(dāng)代碼分支比較少并且確定不會(huì)增加時(shí)，使用這種方式也是完全 ok 的，但是當(dāng)分支比較多，并且后面可能會(huì)增加分支判斷條件時(shí)，這種方式就違反了單一職責(zé)和開閉原則，因此對(duì)于我們開發(fā)工作中遇到這種情況，首先想到的是應(yīng)該去優(yōu)化這種代碼中的“壞味道”，其中的方法之一就是考慮能不能用策略模式去重寫，將代碼和業(yè)務(wù)邏輯解耦，這樣才有利于后續(xù)的維護(hù)工作。

策略模式，簡單來說就是通過實(shí)現(xiàn)接口來重寫不同的方法，從而通過上下文自動(dòng)獲取選擇的策略方法并執(zhí)行。

實(shí)踐使用

以下基于 SpringBoot 的依賴注入實(shí)現(xiàn)策略模式。假設(shè)場(chǎng)景如下：某個(gè)客戶需要訂購多個(gè)資源，每個(gè)資源在不同資源池中，不同資源池下的資源也都不一樣，在此處把原始的 if-else 代碼邏輯優(yōu)化為策略模式。

首先我們實(shí)現(xiàn)一個(gè) ResourceStrategy 接口，并定義選擇資源的抽象方法：

public interface ResourceStrategy { String orderInformation(String id);}

然后根據(jù) if-else 中的判斷條件，構(gòu)造三個(gè)資源類實(shí)現(xiàn) ResourceStrategy 接口：

@Component('A')public class ResourceA implements ResourceStrategy { @override public String orderInformation(String id){ System.out.println('策略選擇：Strategy A'); return 'A'; }}

@Component('B')public class ResourceB implements ResourceStrategy { @override public String orderInformation(String id){ System.out.println('策略選擇：Strategy B'); return 'B'; }}

@Component('C')public class ResourceC implements ResourceStrategy { @override public String orderInformation(String id){ System.out.println('策略選擇：Strategy C'); return 'C'; }}

注意其中每個(gè)類都需要標(biāo)注策略類別名稱。

然后我們需要寫一個(gè) SimpleContext 類來存儲(chǔ)我們的策略類別，這時(shí)候就用到了 Spring 的依賴注入和自動(dòng)發(fā)現(xiàn)。

@Servicepublic class SimpleContextService { @Autowired private final Map<String, Strategy> strategyMap = new ConcurrentHashMap<>(); public SimpleContext(Map<String, ResourceStrategy > strategyMap) {this.strategyMap.clear();strategyMap.forEach(strategyMap::put); } public String getResource(String poolId){return strategyMap.get(poolId).orderInformation(poolId); }}

接下來就是我們的實(shí)際調(diào)用場(chǎng)景了~，如下：

@RestController@RequestMapping('/test')public class TestController { @Autowired private SimpleContextService contextService; @GetMapping('/choose') public String choose(@RequestParam String poolId){return simpleContext.getResource(poolId); } }

那么當(dāng)我們的入?yún)?poolId 傳入 “A” 時(shí)，返回的結(jié)果如下：

策略選擇：Strategy AA

同理，不同傳參都會(huì)進(jìn)入不同的策略執(zhí)行方法。過這個(gè)簡單的 demo，就可以看到通過獲取輸入不同的資源池 id，可以自動(dòng)的拿到不同的資源。通過實(shí)踐總結(jié)下來，使用策略模式的好處就是通過一個(gè)封裝的上下文可以自由的切換不同的算法，省去多重判斷，同時(shí)可以具有很好的擴(kuò)展性。

總結(jié)

從上面可以看出，策略模式的優(yōu)缺點(diǎn)十分明顯，在我們實(shí)際的業(yè)務(wù)中，也需要看情況使用。

優(yōu)點(diǎn)： 策略模式符合開閉原則 代碼簡潔，從上下文自動(dòng)獲取條件轉(zhuǎn)移語句 使用策略模式可以提高算法的保密性和安全性 缺點(diǎn)： 每個(gè)策略都需要單獨(dú)實(shí)現(xiàn)一個(gè)類，當(dāng)策略很多時(shí)，會(huì)產(chǎn)生大量的策略類，會(huì)使代碼出現(xiàn)“膨脹” 客戶端必須知道所有的策略 策略模式的一系列算法地位是平等的，是可以相互替換的，事實(shí)上構(gòu)成了一個(gè)扁平的算法結(jié)構(gòu)，也就是在一個(gè)策略接口下，有多個(gè)平等的策略算法，就相當(dāng)于兄弟算法。而且在運(yùn)行時(shí)刻只有一個(gè)算法被使用，這就限制了算法使用的層級(jí)，使用的時(shí)候不能被嵌套使用

以上就是SpringBoot策略模式的實(shí)踐使用的詳細(xì)內(nèi)容，更多關(guān)于SpringBoot策略模式的使用的資料請(qǐng)關(guān)注好吧啦網(wǎng)其它相關(guān)文章！