前言
if else過(guò)多的話(huà)，一般都是用策略模式來(lái)進(jìn)行重構(gòu)，策略模式也非常的簡(jiǎn)單。先定義一個(gè)接口，各種處理分支實(shí)現(xiàn)這個(gè)接口，定義好 條件->處理類(lèi)的映射關(guān)系，然后根據(jù)條件找到響應(yīng)的處理類(lèi)執(zhí)行即可，當(dāng)有新的分支的話(huà)，只需要增加一個(gè)接口實(shí)現(xiàn)類(lèi)，增加一個(gè)條件->映射類(lèi)的映射關(guān)系即可。還是很好容易理解的
介紹
不出意外，這應(yīng)該是年前最后一次分享，本次來(lái)一點(diǎn)實(shí)際開(kāi)發(fā)中會(huì)用到的小技巧。
比如平時(shí)大家是否都會(huì)寫(xiě)類(lèi)似這樣的代碼：
條件少還好，一旦 else if 過(guò)多這里的邏輯將會(huì)比較混亂，并很容易出錯(cuò)。
比如這樣：
摘自 cim 中的一個(gè)客戶(hù)端命令的判斷條件。
剛開(kāi)始條件較少，也就沒(méi)管那么多直接寫(xiě)的；現(xiàn)在功能多了導(dǎo)致每次新增一個(gè) else 條件我都得仔細(xì)核對(duì)，生怕影響之前的邏輯。
這次終于忍無(wú)可忍就把他重構(gòu)了，重構(gòu)之后這里的結(jié)構(gòu)如下：
最后直接變?yōu)閮尚写a，簡(jiǎn)潔了許多。
而之前所有的實(shí)現(xiàn)邏輯都單獨(dú)抽取到其他實(shí)現(xiàn)類(lèi)中。
這樣每當(dāng)我需要新增一個(gè) else 邏輯，只需要新增一個(gè)類(lèi)實(shí)現(xiàn)同一個(gè)接口便可完成。每個(gè)處理邏輯都互相獨(dú)立互不干擾。
實(shí)現(xiàn)
按照目前的實(shí)現(xiàn)畫(huà)了一個(gè)草圖。
整體思路如下：
- 定義一個(gè) InnerCommand 接口，其中有一個(gè) process 函數(shù)交給具體的業(yè)務(wù)實(shí)現(xiàn)。
- 根據(jù)自己的業(yè)務(wù)，會(huì)有多個(gè)類(lèi)實(shí)現(xiàn) InnerCommand 接口；這些實(shí)現(xiàn)類(lèi)都會(huì)注冊(cè)到 Spring Bean 容器中供之后使用。
- 通過(guò)客戶(hù)端輸入命令，從 Spring Bean 容器中獲取一個(gè) InnerCommand 實(shí)例。
- 執(zhí)行最終的 process 函數(shù)。
主要想實(shí)現(xiàn)的目的就是不在有多個(gè)判斷條件，只需要根據(jù)當(dāng)前客戶(hù)端的狀態(tài)動(dòng)態(tài)的獲取 InnerCommand 實(shí)例。
從源碼上來(lái)看最主要的就是 InnerCommandContext 類(lèi)，他會(huì)根據(jù)當(dāng)前客戶(hù)端命令動(dòng)態(tài)獲取 InnerCommand 實(shí)例。
- 第一步是獲取所有的 InnerCommand 實(shí)例列表。
- 根據(jù)客戶(hù)端輸入的命令從第一步的實(shí)例列表中獲取類(lèi)類(lèi)型。
- 根據(jù)類(lèi)類(lèi)型從 Spring 容器中獲取具體實(shí)例對(duì)象。
因此首先第一步需要維護(hù)各個(gè)命令所對(duì)應(yīng)的類(lèi)類(lèi)型。
所以在之前的枚舉中就維護(hù)了命令和類(lèi)類(lèi)型的關(guān)系，只需要知道命令就能知道他的類(lèi)類(lèi)型。
這樣才能滿(mǎn)足只需要兩行代碼就能替換以前復(fù)雜的 if else，同時(shí)也能靈活擴(kuò)展。
總結(jié)
當(dāng)然還可以做的更靈活一些，比如都不需要顯式的維護(hù)命令和類(lèi)類(lèi)型的對(duì)應(yīng)關(guān)系。
只需要在應(yīng)用啟動(dòng)時(shí)掃描所有實(shí)現(xiàn)了 InnerCommand 接口的類(lèi)即可，在 cicada 中有類(lèi)似實(shí)現(xiàn)，感興趣的可以自行查看。
