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

前言

本次來一點實際開發中會用到的小技巧。分佈式

好比平時你們是否都會寫相似這樣的代碼:函數

 
if(a){ //dosomething }else if(b){ //doshomething }else if(c){ //doshomething } else{ ////doshomething }

條件少還好,一旦 else if 過多這裏的邏輯將會比較混亂,並很容易出錯。微服務

好比這樣:源碼分析

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring,MyBatis,Netty源碼分析的朋友能夠加個人Java高級交流:854630135,羣裏有阿里大牛直播講解技術,以及Java大型互聯網技術的視頻免費分享給你們。性能

 

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

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

此次終於忍無可忍就把他重構了,重構以後這裏的結構以下:code

 

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

而以前全部的實現邏輯都單獨抽取到其餘實現類中。對象

 

 

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

實現

 

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

總體思路以下:

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

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

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

 

  • 第一步是獲取全部的 InnerCommand 實例列表。
  • 根據客戶端輸入的命令從第一步的實例列表中獲取類類型。
  • 根據類類型從 Spring 容器中獲取具體實例對象。

所以首先第一步須要維護各個命令所對應的類類型。

 

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring,MyBatis,Netty源碼分析的朋友能夠加個人Java高級交流:854630135,羣裏有阿里大牛直播講解技術,以及Java大型互聯網技術的視頻免費分享給你們。

因此在以前的枚舉中就維護了命令和類類型的關係,只須要知道命令就能知道他的類類型。

這樣才能知足只須要兩行代碼就能替換之前複雜的 if else,同時也能靈活擴展。

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

總結

固然還能夠作的更靈活一些,好比都不須要顯式的維護命令和類類型的對應關係。

只須要在應用啓動時掃描全部實現了 InnerCommand 接口的類便可。

若是想學習Java工程化、高性能及分佈式、深刻淺出。微服務、Spring,MyBatis,Netty源碼分析的朋友能夠加個人Java高級交流:854630135,羣裏有阿里大牛直播講解技術,以及Java大型互聯網技術的視頻免費分享給你們。

相關文章
相關標籤/搜索