您好,登錄后才能下訂單哦!
這篇“SpringBoot的策略模式的應(yīng)用場景實(shí)例代碼分析”文章的知識點(diǎn)大部分人都不太理解,所以小編給大家總結(jié)了以下內(nèi)容,內(nèi)容詳細(xì),步驟清晰,具有一定的借鑒價(jià)值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來看看這篇“SpringBoot的策略模式的應(yīng)用場景實(shí)例代碼分析”文章吧。
在實(shí)際業(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 代碼在每個(gè)分支都會判斷分支類型,然后執(zhí)行不同的方法獲取結(jié)果,當(dāng)代碼分支比較少并且確定不會增加時(shí),使用這種方式也是完全 ok 的,但是當(dāng)分支比較多,并且后面可能會增加分支判斷條件時(shí),這種方式就違反了單一職責(zé)和開閉原則,因此對于我們開發(fā)工作中遇到這種情況,首先想到的是應(yīng)該去優(yōu)化這種代碼中的“壞味道”,其中的方法之一就是考慮能不能用策略模式去重寫,將代碼和業(yè)務(wù)邏輯解耦,這樣才有利于后續(xù)的維護(hù)工作。
策略模式,簡單來說就是通過實(shí)現(xiàn)接口來重寫不同的方法,從而通過上下文自動獲取選擇的策略方法并執(zhí)行。
以下基于 SpringBoot 的依賴注入實(shí)現(xiàn)策略模式。假設(shè)場景如下:某個(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 類來存儲我們的策略類別,這時(shí)候就用到了 Spring 的依賴注入和自動發(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);
}
}
接下來就是我們的實(shí)際調(diào)用場景了~,如下:
@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
同理,不同傳參都會進(jìn)入不同的策略執(zhí)行方法。過這個(gè)簡單的 demo,就可以看到通過獲取輸入不同的資源池 id,可以自動的拿到不同的資源。
通過實(shí)踐總結(jié)下來,使用策略模式的好處就是通過一個(gè)封裝的上下文可以自由的切換不同的算法,省去多重判斷,同時(shí)可以具有很好的擴(kuò)展性。
從上面可以看出,策略模式的優(yōu)缺點(diǎn)十分明顯,在我們實(shí)際的業(yè)務(wù)中,也需要看情況使用。
策略模式符合開閉原則
代碼簡潔,從上下文自動獲取條件轉(zhuǎn)移語句
使用策略模式可以提高算法的保密性和安全性
每個(gè)策略都需要單獨(dú)實(shí)現(xiàn)一個(gè)類,當(dāng)策略很多時(shí),會產(chǎn)生大量的策略類,會使代碼出現(xiàn)“膨脹”
客戶端必須知道所有的策略
策略模式的一系列算法地位是平等的,是可以相互替換的,事實(shí)上構(gòu)成了一個(gè)扁平的算法結(jié)構(gòu),也就是在一個(gè)策略接口下,有多個(gè)平等的策略算法,就相當(dāng)于兄弟算法。而且在運(yùn)行時(shí)刻只有一個(gè)算法被使用,這就限制了算法使用的層級,使用的時(shí)候不能被嵌套使用
以上就是關(guān)于“SpringBoot的策略模式的應(yīng)用場景實(shí)例代碼分析”這篇文章的內(nèi)容,相信大家都有了一定的了解,希望小編分享的內(nèi)容對大家有幫助,若想了解更多相關(guān)的知識內(nèi)容,請關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。