利用設計模式消除業務程式碼中的 if-else
阿新 • • 發佈：2020-12-24
準備工作：
假設這樣的一個業務場景：有一個自動開票的功能需要實現，在程式裡面需要根據賬單的型別執行對應的處理邏輯。
**以下使用了 Lombok 簡化程式碼！！！**
賬單型別列舉： ```java /** * @author ly-az * @date 12/23/2020 11:34 * 賬單型別 */ public enum BillType { /** * 賬單的型別 */ BT0001, BT0002 } ```
賬單類： ```java /** * @author ly-az * @date 12/23/2020 11:31 * 賬單實體 */ @Data @NoArgsConstructor @AllArgsConstructor public class Bill { /** * 賬單資訊 */ String message; /** * 賬單型別型別(BT0001、BT0002) */ BillType type; } ```
## 方案一：使用策略模式+Map字典 > **策略模式屬於物件的行為模式。其用意是針對一組演算法，將每一個演算法封裝到具有共同介面的獨立的類中，從而使得它們可以相互替換。策略模式使得演算法可以在不影響到客戶端的情況下發生變化。** > ------《JAVA與模式》
也就是說讓我們自己的程式碼不再依賴於呼叫業務程式碼的時的客戶端，能夠根據不同的客戶端執行不同的程式碼，而客戶端只需要呼叫我們的策略介面即可。
在上述場景中，可以把 if-else 分支的程式碼抽取為各種不同的策略實現，而且我們可以把選擇不同策略的實現的程式碼邏輯抽取到一個工廠類中去，這就是策略模式+簡單工廠模式，為了進一步簡化，我們還可以把策略的實現放到一個Map中封裝成字典
看程式碼：
- **抽象策略：**通常由一個介面或抽象類實現。是所有的具體策略類所需的介面。 ```java /** * @author ly-az * @date 12/23/2020 11:46 * @see BillHandleStrategyFactory 策略工廠 * 賬單處理的策略介面
* 有新的型別的賬單時只需要實現這個介面重寫接口裡的實現方法並新增到策略工廠裡面的字典裡即可 */ public interface BillHandleStrategy { /** * 處理方法 * * @param bill 賬單 */ void handleBill(Bill bill); } ``` - **環境：**持有一個策略介面的引用。 ```java /** * @author ly-az * @date 12/23/2020 11:46 */ public class BillStrategyContext { private BillHandleStrategy billHandleStrategy; /** * 設定策略介面 * * @param billHandleStrategy 策略介面 */ public void setBillHandleStrategy(BillHandleStrategy billHandleStrategy) { this.billHandleStrategy = billHandleStrategy; } public void handleBill(Bill bill) { if (billHandleStrategy != null) { billHandleStrategy.handleBill(bill); } } } ``` - **具體的策略實現：**就是處理賬單的策略介面的具體實現，賬單對應的處理者。 ```java /** * @author ly-az * @date 12/23/2020 13:01 * 處理BT0001賬單的策略介面的實現類 */ public class Bt0001BillHandleStrategy implements BillHandleStrategy { @Override public void handleBill(Bill bill) { // 模擬業務處理 System.out.println("開始處理BT0001型別的賬單 > > > " + bill.getMessage() + ". . ."); System.out.println("處理成功！！！"); } } ``` ```java /** * @author ly-az * @date 12/23/2020 13:02 * 處理BT0002型別的策略實現類 */ public class Bt0002BillHandleStrategy implements BillHandleStrategy { @Override public void handleBill(Bill bill) { // 模擬實現業務處理 System.out.println("開始處理BT0002型別的賬單 > > > " + bill.getMessage() + ". . . "); System.out.println("處理成功！！！"); } } ``` - **策略工廠：**用於獲取具體策略的實現類物件 ```java /** * @author ly-az * @date 12/23/2020 13:05 * 策略工廠 */ public class BillHandleStrategyFactory { private static final Map
**測試程式碼： ```java /** * @author ly-az * @date 12/23/2020 13:12 */ public class Test02 { public static void main(String[] args) { //模擬賬單 List
**測試結果：
**
每當有一種新的賬單型別，只需要新增新的賬單處理策略，並新增到BillHandleStrategyFactory中的Map集合。
如果要使得程式符合開閉原則，則需要調整BillHandleStrategyFactory中處理策略的獲取方式。
（好吧，我攤牌了，其實是我太菜了沒有想到怎麼寫ヾ(•ω•`)o） **改進思路：策略模式+註解，通過自定義註解，使用註解標記具體的策略實現類，我們就可以通過反射獲取到具體的策略實現類的例項，然後放置到容器的Map字典中！**
**
** ## 方案二：使用責任鏈模式 顧名思義，責任鏈模式（Chain of Responsibility Pattern）為呼叫請求建立了一個接收者物件的鏈。讓多個物件都有可能接收請求，並將這些物件連線成一條鏈，並且沿著這條鏈傳遞呼叫請求，直到有物件處理它為止。這種型別的設計模式也屬於行為型模式。
發出這個呼叫請求的客戶端並不知道鏈上的哪一個物件會最終處理這個呼叫請求，這使得我們的程式可以在不影響客戶端的情況下動態地重新組織和分配責任。 - **賬單處理的抽像介面** ```java /** * @author ly-az * @date 12/23/2020 14:51 * 賬單的抽象處理介面 */ public interface IBillHandler { /** * 利用責任鏈處理賬單的抽象方法 * @param bill 賬單 * @param handleChain 處理鏈 */ void handleBill(Bill bill, IBillHandleChain handleChain); } ``` - **賬單處理的的具體實現** ```java /** * @author ly-az * @date 12/23/2020 15:14 * 賬單的具體處理者的實現 */ public class Bt0001BillHandler implements IBillHandler { @Override public void handleBill(Bill bill, IBillHandleChain handleChain) { if (BillType.BT0001.equals(bill.getType())) { // 模擬實現業務處理 System.out.println("開始處理BT0001型別的賬單 > > > " + bill.getMessage() + ". . . "); System.out.println("處理成功！！！"); } //處理不了該回執就往下傳遞 else { handleChain.handleBill(bill); } } } ``` ```java /** * @author ly-az * @date 12/23/2020 15:42 * todo */ public class Bt0002BillHandler implements IBillHandler { @Override public void handleBill(Bill bill, IBillHandleChain handleChain) { if (BillType.BT0002.equals(bill.getType())) { // 模擬實現業務處理 System.out.println("開始處理BT0002型別的賬單 > > > " + bill.getMessage() + ". . . "); System.out.println("處理成功！！！"); } //處理不了該回執就往下傳遞 else { handleChain.handleBill(bill); } } } ```
- **責任連結口** ```java /** * @author ly-az * @date 12/23/2020 14:52 * 責任連結口 */ public interface IBillHandleChain { /** * 處理賬單的抽象方法 * * @param bill 賬單 */ void handleBill(Bill bill); } ```
- **責任連結口的實現** ```java /** * @author ly-az * @date 12/23/2020 15:08 * 處理賬單的責任鏈 */ public class BillHandleChain implements IBillHandleChain { /** * 記錄當前處理者位置 */ private int index = 0; /** * 處理者集合 */ private static final List
結果：
**同樣，如果要使得程式符合開閉原則，則需要調整BillHandlerContext中處理者的獲取方式，通過反射的方式，獲取指定包下的所有IBillHandler的實現類。**
**
o(*￣▽￣*)ブ，我想到了這種解決方案下該如何改造使其符合開閉原則！！！
我們需要引入一個反射用的工具類： ```java /** * @author ly-az * @date 12/23/2020 16:00 * 反射工具類 */ public class ReflectionUtil { /** * 定義類集合（用於存放所有載入的類的映象） */ private static final Set
**
## 小結 if-else以及switch-case 這種分支判斷的方式對於分支邏輯不多的簡單業務，還是更加直觀高效的。但是對於業務複雜，分支邏輯多的情況下，採用一下適當的設計模式，會讓程式碼更加清晰，容易維護，但同時類或方法數量也是倍增的。**我們需要對業務做好充分分析，避免一上來就設計模式，避免過度設