我想談一談這個(gè)話(huà)題是因?yàn)槲业?a target="_blank">上一篇博客有一些朋友回復(fù)，說(shuō)if-else過(guò)多的分支可以使用switch或者責(zé)任鏈模式等等方式來(lái)優(yōu)化。確實(shí)，這是一個(gè)小問(wèn)題，不過(guò)我們還是可以整理一下這個(gè)小問(wèn)題的重構(gòu)方式。

為什么要優(yōu)化？

你沒(méi)有看錯(cuò)。這是要放在第一條談?wù)摰摹?/p>

有許多人會(huì)說(shuō)，疊起來(lái)一堆if-else分支，代碼就不優(yōu)雅了?？墒?，怎樣去定義“優(yōu)雅”的概念呢？再退一步說(shuō)，即便不“優(yōu)雅”，又有什么問(wèn)題？

對(duì)于這樣一段再普通不過(guò)的代碼：

int code;   
if("Name".equals(str))   
    code = 0;   
else if("Age".equals(str))   
    code = 1;   
else if("Address".equals(str))   
    code = 2;   
... 

可以有好多種重構(gòu)方式，但是使用這樣的代碼，雖然簡(jiǎn)陋，但在大多數(shù)情況下，并不會(huì)影響什么，比如，對(duì)可維護(hù)性沒(méi)有影響。當(dāng)然，如果你發(fā)現(xiàn)其中確有不好的一面，那就要考慮重構(gòu)它。換言之，通常你首先要說(shuō)出某段代碼的問(wèn)題（比如，你覺(jué)得這段代碼不符合開(kāi)閉原則，因?yàn)槟阆Ｍ３诌@段代碼閉合穩(wěn)定），那么才去存在重構(gòu)的必要，而不要總是使用“優(yōu)雅”和“簡(jiǎn)潔”搪塞疑問(wèn)。幾乎所有的書(shū)上都說(shuō)要寫(xiě)出優(yōu)雅的、簡(jiǎn)潔的代碼，這本身無(wú)可厚非，但是事物需要使用自己的判斷，可不要被習(xí)慣性地洗了腦。

在我前一家公司，是典型的通訊和傳統(tǒng)軟件的公司，代碼質(zhì)量普遍不錯(cuò)，但是很多時(shí)候，會(huì)看到許許多多不夠優(yōu)雅的代碼——也許你覺(jué)得不夠簡(jiǎn)潔、美觀，但是下代碼嚴(yán)謹(jǐn)、清晰，我覺(jué)得這就很好。反之，某一些精巧的設(shè)計(jì)，可能會(huì)帶來(lái)可閱讀性和可理解性下降的問(wèn)題。

尋找代替分支判斷的方式

接下去我們?cè)賮?lái)考慮怎么樣去重構(gòu)優(yōu)化過(guò)多的if-else分支。

程序邏輯最基本的組成就是分支、判斷和循環(huán)。而過(guò)多if-else正是由于在某一個(gè)變化的點(diǎn)上，有許多判斷條件和結(jié)果分支造成的。所以最基本的解決辦法就是把多個(gè)判斷條件合成一個(gè)，也就是把若干個(gè)分支合成一個(gè)。

但是在大多數(shù)情況下，條件判斷的分支都是無(wú)法合并的。所以，我們需要把這個(gè)變化點(diǎn)通過(guò)別的途徑封裝起來(lái)，而不是采用if-else。

1. 用一個(gè)Map可以做到，if-else的變化點(diǎn)使用Map的get方法來(lái)代替：

Map typeCodeMap = new HashMap();   
typeCodeMap.put("Name", 0);   
typeCodeMap.put("Age", 1);   
typeCodeMap.put("Address", 2);   
...   
int code = typeCode.get(type); 

2. 枚舉：

public enum Codes {   
    Name(0), Age(1), Address(2);   
        
    public int code;   
    Codes(int code){   
        this.code = code;   
    }   
}   
    
//使用：   
int code = Codes.valueOf(str).code; 

3. 多態(tài)：

ICode iCode = (ICode)Class.forName("com.xxx." + str).newInstance();   
int code = iCode.getCode(); 

當(dāng)然，如果僅考慮從String轉(zhuǎn)向int這樣的轉(zhuǎn)換，用這樣的方式來(lái)簡(jiǎn)化分支判斷邏輯，這個(gè)方式、這個(gè)例子不是很恰當(dāng)。當(dāng)然，這樣的方式經(jīng)常被用來(lái)做從字符串到具體對(duì)象的轉(zhuǎn)換。

還有一些朋友說(shuō)的這個(gè)模式那個(gè)模式來(lái)解決多if-else的問(wèn)題，這些都是正確的，當(dāng)然本質(zhì)上也無(wú)一例外基于多態(tài)來(lái)實(shí)現(xiàn)的，所以我就不提及了。這些都不錯(cuò)，至少比那些老說(shuō)用switch來(lái)代替if-else的有價(jià)值多了 :)

最后，對(duì)于如此小的一個(gè)問(wèn)題，我要補(bǔ)充說(shuō)明的一點(diǎn)是，看不得大片if-else和看不得大片new關(guān)鍵字一樣，我覺(jué)得這是許多Java程序員的既有觀念或者說(shuō)習(xí)慣，甚至通病——這并不好。Java最有價(jià)值的地方不是它的語(yǔ)義語(yǔ)法也不是它的虛擬機(jī)跨平臺(tái)和有多高性能，而在于它的社區(qū)它的無(wú)比豐富的類(lèi)庫(kù)，在于使用它的人可以從設(shè)計(jì)上和宏觀上去思考問(wèn)題。但是Java程序員，也包括我在內(nèi)，很容易把這條路走得過(guò)于極端，比如遍地的Factory，比如漫山遍野的配置，比如永遠(yuǎn)也不會(huì)被復(fù)用的可復(fù)用代碼，比如永遠(yuǎn)也不會(huì)被擴(kuò)展的可擴(kuò)展代碼，還比如從前到后由內(nèi)到外的分層，一層又一層。相對(duì)于這些方面無(wú)止境的追求，我們還是專(zhuān)注于要解決的問(wèn)題，多寫(xiě)一些清晰可用的代碼吧。

原文鏈接：http://www.raychase.net/1241