前言

在實(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é)和開(kāi)閉原則，因此對(duì)于我們開(kāi)發(fā)工作中遇到這種情況，首先想到的是應(yīng)該去優(yōu)化這種代碼中的“壞味道”，其中的方法之一就是考慮能不能用策略模式去重寫，將代碼和業(yè)務(wù)邏輯解耦，這樣才有利于后續(xù)的維護(hù)工作。

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

實(shí)踐使用

以下基于 SpringBoot 的依賴注入實(shí)現(xiàn)策略模式。假設(shè)場(chǎng)景如下：某個(gè)客戶需要訂購(gòu)多個(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 類來(lái)存儲(chǔ)我們的策略類別，這時(shí)候就用到了 Spring 的依賴注入和自動(dòng)發(fā)現(xiàn)。

@Service
public 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);
    }
}

接下來(lái)就是我們的實(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 A
A

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

總結(jié)

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

優(yōu)點(diǎn)：

• 策略模式符合開(kāi)閉原則
• 代碼簡(jiǎn)潔，從上下文自動(dòng)獲取條件轉(zhuǎn)移語(yǔ)句
• 使用策略模式可以提高算法的保密性和安全性
  

缺點(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)注腳本之家其它相關(guān)文章！

最新評(píng)論