知識星球
精品專欄
作者：crossoverJie
出處：https://segmentfault.com/a/1190000018070781
前言
不出意外，這應該是年前最後一次分享，本次來一點實際開發中會用到的小技巧。
比如平時大家是否都會寫類似這樣的程式碼：
if(a){//dosomething}else if(b){//doshomething}else if(c){//doshomething} else{////doshomething}
條件少還好，一旦 elseif 過多這裡的邏輯將會比較混亂，並很容易出錯。
比如這樣：
摘自 cim 中的一個客戶端命令的判斷條件。
剛開始條件較少，也就沒管那麼多直接寫的；現在功能多了導致每次新增一個 else 條件我都得仔細核對，生怕影響之前的邏輯。
這次終於忍無可忍就把他重構了，重構之後這裡的結構如下：
最後直接變為兩行程式碼，簡潔了許多。
而之前所有的實現邏輯都單獨抽取到其他實現類中。
這樣每當我需要新增一個 else 邏輯，只需要新增一個類實現同一個介面便可完成。每個處理邏輯都互相獨立互不幹擾。
實現
按照目前的實現畫了一個草圖。
整體思路如下：
- 定義一個
InnerCommand介面，其中有一個process函式交給具體的業務實現。 - 根據自己的業務，會有多個類實現
InnerCommand介面；這些實現類都會註冊到SpringBean容器中供之後使用。 - 透過客戶端輸入命令，從
SpringBean容器中獲取一個InnerCommand實體。 - 執行最終的
process函式。
主要想實現的目的就是不在有多個判斷條件，只需要根據當前客戶端的狀態動態的獲取 InnerCommand 實體。
從原始碼上來看最主要的就是 InnerCommandContext 類，他會根據當前客戶端命令動態獲取 InnerCommand 實體。
- 第一步是獲取所有的
InnerCommand實體串列。 - 根據客戶端輸入的命令從第一步的實體串列中獲取型別別。
- 根據型別別從
Spring容器中獲取具體實體物件。
因此首先第一步需要維護各個命令所對應的型別別。
所以在之前的列舉中就維護了命令和型別別的關係，只需要知道命令就能知道他的型別別。
這樣才能滿足只需要兩行程式碼就能替換以前複雜的 ifelse，同時也能靈活擴充套件。
InnerCommand instance = innerCommandContext.getInstance(msg);instance.process(msg) ;
總結
當然還可以做的更靈活一些，比如都不需要顯式的維護命令和型別別的對應關係。
只需要在應用啟動時掃描所有實現了 InnerCommand 介面的類即可，在 cicada 中有類似實現，感興趣的可以自行檢視。
這樣一些小技巧希望對你有所幫助。
以上所有原始碼可以在這裡檢視：
https://github.com/crossoverJie/cim
