前言

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

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

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

實踐使用

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

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

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

然后根據(jù) if-else 中的判斷條件，構(gòu)造三個資源類實現(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'; }}

注意其中每個類都需要標注策略類別名稱。

然后我們需要寫一個 SimpleContext 類來存儲我們的策略類別，這時候就用到了 Spring 的依賴注入和自動發(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); }}

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

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

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

策略選擇：Strategy AA

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

總結(jié)

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

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

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