您好,登錄后才能下訂單哦!
這篇“SpringBoot的策略模式的應用場景實例代碼分析”文章的知識點大部分人都不太理解,所以小編給大家總結了以下內容,內容詳細,步驟清晰,具有一定的借鑒價值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來看看這篇“SpringBoot的策略模式的應用場景實例代碼分析”文章吧。
在實際業務代碼中,我們經常會碰到這樣的代碼:
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 代碼在每個分支都會判斷分支類型,然后執行不同的方法獲取結果,當代碼分支比較少并且確定不會增加時,使用這種方式也是完全 ok 的,但是當分支比較多,并且后面可能會增加分支判斷條件時,這種方式就違反了單一職責和開閉原則,因此對于我們開發工作中遇到這種情況,首先想到的是應該去優化這種代碼中的“壞味道”,其中的方法之一就是考慮能不能用策略模式去重寫,將代碼和業務邏輯解耦,這樣才有利于后續的維護工作。
策略模式,簡單來說就是通過實現接口來重寫不同的方法,從而通過上下文自動獲取選擇的策略方法并執行。
以下基于 SpringBoot 的依賴注入實現策略模式。假設場景如下:某個客戶需要訂購多個資源,每個資源在不同資源池中,不同資源池下的資源也都不一樣,在此處把原始的 if-else 代碼邏輯優化為策略模式。
首先我們實現一個 ResourceStrategy 接口,并定義選擇資源的抽象方法:
public interface ResourceStrategy {
String orderInformation(String id);
}
然后根據 if-else 中的判斷條件,構造三個資源類實現 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 的依賴注入和自動發現。
@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);
}
}
接下來就是我們的實際調用場景了~,如下:
@RestController
@RequestMapping("/test")
public class TestController {
@Autowired
private SimpleContextService contextService;
@GetMapping("/choose")
public String choose(@RequestParam String poolId){
return simpleContext.getResource(poolId);
}
}
那么當我們的入參 poolId 傳入 “A” 時,返回的結果如下:
策略選擇:Strategy A A
同理,不同傳參都會進入不同的策略執行方法。過這個簡單的 demo,就可以看到通過獲取輸入不同的資源池 id,可以自動的拿到不同的資源。
通過實踐總結下來,使用策略模式的好處就是通過一個封裝的上下文可以自由的切換不同的算法,省去多重判斷,同時可以具有很好的擴展性。
從上面可以看出,策略模式的優缺點十分明顯,在我們實際的業務中,也需要看情況使用。
策略模式符合開閉原則
代碼簡潔,從上下文自動獲取條件轉移語句
使用策略模式可以提高算法的保密性和安全性
每個策略都需要單獨實現一個類,當策略很多時,會產生大量的策略類,會使代碼出現“膨脹”
客戶端必須知道所有的策略
策略模式的一系列算法地位是平等的,是可以相互替換的,事實上構成了一個扁平的算法結構,也就是在一個策略接口下,有多個平等的策略算法,就相當于兄弟算法。而且在運行時刻只有一個算法被使用,這就限制了算法使用的層級,使用的時候不能被嵌套使用
以上就是關于“SpringBoot的策略模式的應用場景實例代碼分析”這篇文章的內容,相信大家都有了一定的了解,希望小編分享的內容對大家有幫助,若想了解更多相關的知識內容,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。