歡迎光臨
每天分享高質量文章

利用策略樣式優化過多 if else 代碼

精品專欄

 

作者:crossoverJie

出處:https://segmentfault.com/a/1190000018070781


前言

不出意外,這應該是年前最後一次分享,本次來一點實際開發中會用到的小技巧。

比如平時大家是否都會寫類似這樣的代碼:

  1. if(a){
  2. //dosomething
  3. }else if(b){
  4. //doshomething
  5. }else if(c){
  6. //doshomething
  7. } else{
  8. ////doshomething
  9. }

條件少還好,一旦 elseif 過多這裡的邏輯將會比較混亂,並很容易出錯。

比如這樣:

摘自 cim 中的一個客戶端命令的判斷條件。

剛開始條件較少,也就沒管那麼多直接寫的;現在功能多了導致每次新增一個 else 條件我都得仔細核對,生怕影響之前的邏輯。

這次終於忍無可忍就把他重構了,重構之後這裡的結構如下:

最後直接變為兩行代碼,簡潔了許多。

而之前所有的實現邏輯都單獨抽取到其他實現類中。

這樣每當我需要新增一個 else 邏輯,只需要新增一個類實現同一個接口便可完成。每個處理邏輯都互相獨立互不干擾。

實現

按照目前的實現畫了一個草圖。

整體思路如下:

  • 定義一個 InnerCommand 接口,其中有一個 process 函式交給具體的業務實現。
  • 根據自己的業務,會有多個類實現 InnerCommand 接口;這些實現類都會註冊到 SpringBean 容器中供之後使用。
  • 通過客戶端輸入命令,從 SpringBean 容器中獲取一個 InnerCommand 實體。
  • 執行最終的 process 函式。

主要想實現的目的就是不在有多個判斷條件,只需要根據當前客戶端的狀態動態的獲取 InnerCommand 實體。

從原始碼上來看最主要的就是 InnerCommandContext 類,他會根據當前客戶端命令動態獲取 InnerCommand 實體。

  • 第一步是獲取所有的 InnerCommand 實體串列。
  • 根據客戶端輸入的命令從第一步的實體串列中獲取類型別。
  • 根據類型別從 Spring 容器中獲取具體實體物件。

因此首先第一步需要維護各個命令所對應的類型別。

所以在之前的列舉中就維護了命令和類型別的關係,只需要知道命令就能知道他的類型別。

這樣才能滿足只需要兩行代碼就能替換以前複雜的 ifelse,同時也能靈活擴展。

  1. InnerCommand instance = innerCommandContext.getInstance(msg);
  2. instance.process(msg) ;

總結

當然還可以做的更靈活一些,比如都不需要顯式的維護命令和類型別的對應關係。

只需要在應用啟動時掃描所有實現了 InnerCommand 接口的類即可,在 cicada 中有類似實現,感興趣的可以自行查看。

這樣一些小技巧希望對你有所幫助。

以上所有原始碼可以在這裡查看:

https://github.com/crossoverJie/cim

關於爛代碼的那些事(中)

關於爛代碼的那些事(上)

深入解讀zookeeper一致性原理

阿裡雲Redis開發規範

10分鐘看懂!基於Zookeeper的分佈式鎖

Core Java 併發:理解併發概念

分分鐘解決 MySQL 查詢速度慢與性能差

Java 必須掌握的 20+ 種 Spring 常用註解

為什麼阿裡巴巴禁止開發人員使用isSuccess作為變數名

8種常被忽視的SQL錯誤用法

可能是最全面的G1學習筆記

    赞(0)

    分享創造快樂