本文來自作者投稿，原作者：上帝愛吃蘋果
目前在魔都，貝殼找房是我的僱主，平時關注一些 java 領域相關的技術，希望你們能在這篇文章中找到些有用的東西。個人水平有限，如果文章有錯誤還請指出，在留言區一起交流。
我想大家肯定都或多或少的看過各種“策略模式”的講解、佈道等等，這篇文章就是來好好“澄清”一下策略模式，並嘗試回答以下的問題：
1. 策略模式是如何優化業務邏輯代碼結構的？
2. 殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！
3. 有沒有什麼更好的代碼結構來實現策略模式的嗎？
策略模式是如何優化業務邏輯代碼結構的？
要回答這個問題，我們還得先扒一扒策略模式的定義，從定義着手來理解它
策略模式的教科書定義
它的定義很精簡：一個類的行為或其算法可以在運行時更改。我們把它降維到代碼層面，用人話翻譯一下就是，運行時我給你這個類的方法傳不同的“key”，你這個方法會執行不同的業務邏輯。細品一下，這不就是 if else 乾的事嗎？
策略模式優化了什麼？
其實策略模式的核心思想和 if else如出一轍，根據不同的key動態的找到不同的業務邏輯，那它就只是如此嗎？
實際上，我們口中的策略模式其實就是在代碼結構上調整，用接口+實現類+分派邏輯來使代碼結構可維護性好點。
一般教科書上講解到接口與實現類就結束了，其他博客上會帶上提及分派邏輯。這裏就不啰嗦了。
小結一下，即使用了策略模式，你該寫的業務邏輯照常寫，到邏輯分派的時候，還是變相的if else。而它的優化點是抽象了出了接口，將業務邏輯封裝成一個一個的實現類，任意地替換。在複雜場景（業務邏輯較多）時比直接 if else 來的好維護些。
殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！
我想小夥伴們經常有這樣的不滿，我的業務邏輯就3 4 行，你給我整一大堆類定義？有必要這麼麻煩嗎？我看具體的業務邏輯還需要去不同的類中，簡單點行不行。
其實我們所不滿的就是策略模式帶來的缺點：
1、策略類會增多
2、業務邏輯分散到各個實現類中，而且沒有一個地方可以俯視整個業務邏輯
針對傳統策略模式的缺點，在這分享一個實現思路，這個思路已經幫我們團隊解決了多個複雜if else的業務場景，理解上比較容易，代碼上需要用到Java8的特性——利用Map與函數式接口來實現。
直接show代碼結構：為了簡單演示一個思路，代碼用String 類型來模擬一個業務BO
其中：
-
getCheckResult() 為傳統的做法
-
getCheckResultSuper()則事先在Map中定義好了“判斷條件”與“業務邏輯”的映射關係,具體講解請看代碼註釋
/**
* 某個業務服務類
*/
@Service
public class BizService {
/**
* 傳統的 if else 解決方法
* 當每個業務邏輯有 3 4 行時，用傳統的策略模式不值得，直接的if else又顯得不易讀
*/
public String getCheckResult(String order) {
if ("校驗1".equals(order)) {
return "執行業務邏輯1";
} else if ("校驗2".equals(order)) {
return "執行業務邏輯2";
}else if ("校驗3".equals(order)) {
return "執行業務邏輯3";
}else if ("校驗4".equals(order)) {
return "執行業務邏輯4";
}else if ("校驗5".equals(order)) {
return "執行業務邏輯5";
}else if ("校驗6".equals(order)) {
return "執行業務邏輯6";
}else if ("校驗7".equals(order)) {
return "執行業務邏輯7";
}else if ("校驗8".equals(order)) {
return "執行業務邏輯8";
}else if ("校驗9".equals(order)) {
return "執行業務邏輯9";
}
return "不在處理的邏輯中返回業務錯誤";
}
/**
* 業務邏輯分派Map
* Function為函數式接口，下面代碼中 Function<String, String> 的含義是接收一個Stirng類型的變量，返回一個String類型的結果
*/
private Map<String, Function<String, String>> checkResultDispatcher = new HashMap<>();
/**
* 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
*/
@PostConstruct
public void checkResultDispatcherInit() {
checkResultDispatcher.put("校驗1", order -> String.format("對%s執行業務邏輯1", order));
checkResultDispatcher.put("校驗2", order -> String.format("對%s執行業務邏輯2", order));
checkResultDispatcher.put("校驗3", order -> String.format("對%s執行業務邏輯3", order));
checkResultDispatcher.put("校驗4", order -> String.format("對%s執行業務邏輯4", order));
checkResultDispatcher.put("校驗5", order -> String.format("對%s執行業務邏輯5", order));
checkResultDispatcher.put("校驗6", order -> String.format("對%s執行業務邏輯6", order));
checkResultDispatcher.put("校驗7", order -> String.format("對%s執行業務邏輯7", order));
checkResultDispatcher.put("校驗8", order -> String.format("對%s執行業務邏輯8", order));
checkResultDispatcher.put("校驗9", order -> String.format("對%s執行業務邏輯9", order));
}
public String getCheckResultSuper(String order) {
//從邏輯分派Dispatcher中獲得業務邏輯代碼，result變量是一段lambda表達式
Function<String, String> result = checkResultDispatcher.get(order);
if (result != null) {
//執行這段表達式獲得String類型的結果
return result.apply(order);
}
return "不在處理的邏輯中返回業務錯誤";
}
}
通過http調用一下看看效果：
/**
* 模擬一次http調用
*/
@RestController
public class BizController {
@Autowired
private BizService bizService;
@PostMapping("/v1/biz/testSuper")
public String test2(String order) {
return bizService.getCheckResultSuper(order);
}
}
這是個簡單的demo演示，之後會舉一些複雜的場景案例。
魯迅曾說過，“每解決一個問題，就會因出更多的問題”。我們一起來看看這樣的實現有什麼好處，會帶來什麼問題。
好處很直觀：
- 在一段代碼里直觀的看到”判斷條件”與業務邏輯的映射關係
- 不需要單獨定義接口與實現類，直接使用現有的函數式接口（什麼？不知道函數式接口？快去了解），而實現類直接就是業務代碼本身。
不好的點：
- 需要團隊成員對lambda表達式有所了解(什麼？Java14都出來了還有沒用上Java8新特性的小夥伴？)
接下來我舉幾個在業務中經常遇到的if else場景，並用Map+函數式接口的方式來解決它
在真實業務場景問題的解決思路
有的小夥伴會說，我的判斷條件有多個啊，而且很複雜，你之前舉個例子只有單個判斷邏輯，而我有多個判斷邏輯該怎麼辦呢？
很好解決：寫一個判斷邏輯的方法，Map的key由方法計算出
/**
* 某個業務服務類
*/
@Service
public class BizService {
private Map<String, Function<String, String>> checkResultDispatcherMuti = new HashMap<>();
/**
* 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
*/
@PostConstruct
public void checkResultDispatcherMuitInit() {
checkResultDispatcherMuti.put("key_訂單1", order -> String.format("對%s執行業務邏輯1", order));
checkResultDispatcherMuti.put("key_訂單1_訂單2", order -> String.format("對%s執行業務邏輯2", order));
checkResultDispatcherMuti.put("key_訂單1_訂單2_訂單3", order -> String.format("對%s執行業務邏輯3", order));
}
public String getCheckResultMuti(String order, int level) {
//寫一段生成key的邏輯：
String ley = getDispatcherKey(order, level);
Function<String, String> result = checkResultDispatcherMuti.get(ley);
if (result != null) {
//執行這段表達式獲得String類型的結果
return result.apply(order);
}
return "不在處理的邏輯中返回業務錯誤";
}
/**
* 判斷條件方法
*/
private String getDispatcherKey(String order, int level) {
StringBuilder key = new StringBuilder("key");
for (int i = 1; i <= level; i++) {
key.append("_" + order + i);
}
return key.toString();
}
}
用http模擬一下：
/**
* 模擬一次http調用
*/
@RestController
public class BizController {
@Autowired
private BizService bizService;
@PostMapping("/v1/biz/testMuti")
public String test1(String order, Integer level) {
return bizService.getCheckResultMuti(order, level);
}
}
只要設計好你的key的生成規則就好。
還有小夥伴會問：我的業務邏輯有很多很多行，在checkResultDispatcherMuitInit()方法的Map中直接寫不會很長嗎？
直接寫當然長了，我們可以抽象出一個service服務專門放業務邏輯，然後在定義中調用它就好了：
提供一個業務邏輯單元：
/**
* 提供業務邏輯單元
*/
@Service
public class BizUnitService {
public String bizOne(String order) {
return order + "各種花式操作1";
}
public String bizTwo(String order) {
return order + "各種花式操作2";
}
public String bizThree(String order) {
return order + "各種花式操作3";
}
}
/**
* 某個業務服務類
*/
@Service
public class BizService {
@Autowired
private BizUnitService bizUnitService;
private Map<String, Function<String, String>> checkResultDispatcherComX = new HashMap<>();
/**
* 初始化 業務邏輯分派Map 其中value 存放的是 lambda表達式
*/
@PostConstruct
public void checkResultDispatcherComXInit() {
checkResultDispatcherComX.put("key_訂單1", order -> bizUnitService.bizOne(order));
checkResultDispatcherComX.put("key_訂單1_訂單2", order -> bizUnitService.bizTwo(order));
checkResultDispatcherComX.put("key_訂單1_訂單2_訂單3", order -> bizUnitService.bizThree(order));
}
public String getCheckResultComX(String order, int level) {
//寫一段生成key的邏輯：
String ley = getDispatcherComXKey(order, level);
Function<String, String> result = checkResultDispatcherComX.get(ley);
if (result != null) {
//執行這段表達式獲得String類型的結果
return result.apply(order);
}
return "不在處理的邏輯中返回業務錯誤";
}
/**
* 判斷條件方法
*/
private String getDispatcherComXKey(String order, int level) {
StringBuilder key = new StringBuilder("key");
for (int i = 1; i <= level; i++) {
key.append("_" + order + i);
}
return key.toString();
}
}
調用結果：
總結
最後，我們一起嘗試回答以下幾個問題：
1. 策略模式是如何優化業務邏輯代碼結構的？
抽象了出了接口，將業務邏輯封裝成一個一個的實現類，任意地替換。在複雜場景（業務邏輯較多）時比直接 if else 來的好維護些。
2. 殺雞焉用宰牛刀？就是幾個if else場景我需要用到策略模式？！
我們所不滿的其實就是傳統接口實現的缺點： 1、策略類會很多。 2、業務邏輯分散到各個實現類中，而且沒有一個地方可以俯覽整個業務邏輯
3. 有沒有什麼更好的代碼結構來實現策略模式的嗎？
針對傳統策略模式的缺點，分享了利用Map與函數式接口來實現的思路。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能
※台北網頁設計公司這麼多該如何選擇?
※智慧手機時代的來臨，RWD網頁設計為架站首選
※評比南投搬家公司費用收費行情懶人包大公開
※幫你省時又省力,新北清潔一流服務好口碑
※回頭車貨運收費標準
近來積極拓展車用電池事業的南韓化學巨擘 LG Chem Ltd. 宣佈，該公司已敲定價值數億美元的電動車電池供應合約，對象是德國汽車製造商福斯 (Volkswagen AG) 旗下的豪華車廠奧迪 (Audi AG)。 LG Chem 目前為通用汽車 (General Motors Co.)、雷諾 (Renault SA)、福特汽車 (Ford Motor Co.)、現代汽車 (Hyundai Motor Co.) 以及起亞汽車 (Kia Motors Corp.) 等 20 家業者的車用電池供應商。日前 LG Chem 才宣布將與通用汽車等汽車廠商攜手研發一款車用電池，其單次充電的里程數多達 200 英里，為市面上大多數電動車的兩倍以上。 20 日 LG Chem 又傳出好消息，該公司透過聲明表示，會為奧迪的次世代插電式混合動力電動車提供車用電池，總值多達數百億韓圜，而由於奧迪與母公司福斯一起共用了許多汽車平台，因此 LG Chem 認為未來應該能與福斯敲定更多類似的協議。 （圖片來源：）
Saleen Automotive 在改車界享負盛名，無論任何車款經其改裝後，都會變得更快更有勁。最近他們看上了 Tesla 的 Model S 電動車，將其改裝為 Saleen FourSixteen，比起原版本擁有更高性能。 Saleen FourSixteen 採用與 Model S 相同的 416 匹引擎，不過其齒輪比率卻提高至 11.39:1，能大幅提高跑車的加速性能，因此由 0 加速至 100 公里只需 4 秒，比起 Model S 足足快了 1 秒。此外，Saleen FourSixteen 同時亦改善了冷卻系統及防傾桿，與及採用賽車用的車底盤及碳纖維剎車盤。 車廂內部也經過重新設計，將 Model S 原有的五座位改成全真皮的四座位，變成了一部真正的四座位超級電動跑車。該跑車目前已開放預訂，但售價並不便宜，約 15 萬 2 千美元。 （圖片來源：）