傳統(tǒng)思維習(xí)慣分析

　　為什么會(huì)業(yè)務(wù)邏輯層使用if else，其實(shí)使用者的目的也是為了重用，但是這是面向過(guò)程編程的重用，程序員只看到代碼重用，因?yàn)樗吹絠f else幾種情況下大部分代碼都是重復(fù)的，只有個(gè)別不同，因此使用if else可以避免重復(fù)代碼，并且認(rèn)為這是模板Template模式。

　　他范的錯(cuò)誤是：程序員只從代碼運(yùn)行順序這個(gè)方向來(lái)看待它的代碼，這種思維類似水管或串行電路，水沿著水管流動(dòng)（代碼運(yùn)行次序），當(dāng)碰到幾個(gè)分管（子管），就分到這幾個(gè)分管子在流動(dòng)，這里就相當(dāng)于碰到代碼的if else處了。

　　而使用OO，則首先打破這個(gè)代碼由上向下順序等同于運(yùn)行時(shí)的先后循序這個(gè)規(guī)律，代碼結(jié)構(gòu)不由執(zhí)行循序決定，由什么決定呢？由OO設(shè)計(jì)；設(shè)計(jì)模式會(huì)取代這些if else，但是最后總是由一個(gè)Service等總類按照運(yùn)行順序組裝這些OO模塊，只有一處，這處可包含事務(wù)，一般就是Service，EJB中是session bean。

　　一旦需求變化，我們更多的可能是Service中各個(gè)OO模塊，甚至是只改動(dòng)Service中的OO模塊執(zhí)行順序就能符合需求。

　　這里我們也看到OO分離的思路，將以前過(guò)程語(yǔ)言的一個(gè)Main函數(shù)徹底分解，將運(yùn)行順序與代碼其他邏輯分離開(kāi)來(lái)，而不是象面向過(guò)程那樣混亂在一起。所以有人感慨，OO也是要順序的，這是肯定的，要害是運(yùn)行順序要單獨(dú)分離出來(lái)。

　　是否有if else可以看出你有沒(méi)有將運(yùn)行順序分離到家。

設(shè)計(jì)模式的切入口

　　經(jīng)常有人反映，設(shè)計(jì)模式是不錯(cuò)，但是我很難用到，其實(shí)假如你使用if else來(lái)寫(xiě)代碼時(shí)（除顯示控制以外），就是在寫(xiě)業(yè)務(wù)邏輯，只不過(guò)使用簡(jiǎn)單的判定語(yǔ)句來(lái)作為現(xiàn)實(shí)情況的替代者。

　　 還是以大家熟悉的論壇帖子為例子，如ForumMessage是一個(gè)模型，但是實(shí)際中帖子分兩種性質(zhì)：主題貼（第一個(gè)根貼）和回帖（回以前帖子的帖子），這里有一個(gè)樸素的解決方案：
建立一個(gè)ForumMessage，然后在ForumMessage加入isTopic這樣判定語(yǔ)句，注重，你這里一個(gè)簡(jiǎn)單屬性的判定引入，可能導(dǎo)致你的程序其他地方到處存在if else 的判定。

　　假如我們改用另外一種分析實(shí)現(xiàn)思路，以對(duì)象化概念看待，實(shí)際中有主題貼和回帖，就是兩種對(duì)象，但是這兩種對(duì)象大部分是一致的，因此，我將ForumMessage設(shè)為表達(dá)主題貼；然后創(chuàng)建一個(gè)繼續(xù)ForumMessage的子類ForumMessageReply作為回帖，這樣，我在程序地方，如Service中，我已經(jīng)確定這個(gè)Model是回帖了，我就直接下溯為ForumMessageReply即可，這個(gè)有點(diǎn)類似向Collection放入對(duì)象和取出時(shí)的強(qiáng)制類型轉(zhuǎn)換。通過(guò)這個(gè)手段我消滅了以后程序中if else的判定語(yǔ)句出現(xiàn)可能。

　　從這里體現(xiàn)了，假如分析方向錯(cuò)誤，也會(huì)導(dǎo)致誤用模式。

　　討論設(shè)計(jì)模式舉例，不能沒(méi)有業(yè)務(wù)上下文場(chǎng)景的案例，否則無(wú)法決定是否該用模式，下面舉兩個(gè)對(duì)比的例子：

　　第一. 這個(gè)帖子中舉例的第一個(gè)代碼案例是沒(méi)有上下文的，文中只說(shuō)明有一段代碼：

if（case A）{

//do with strategy A

}else(case B){

//do with strategy B

}else(case C){

//do with strategy C

}

}

　　這段代碼只是純粹的代碼，沒(méi)有業(yè)務(wù)功能，所以，在這種情況下，我們就很難確定使用什么模式，就是一定用策略模式等，也逃不過(guò)還是使用if else的命運(yùn)，設(shè)計(jì)模式不是魔法，不能將一段毫無(wú)意義的代碼變得簡(jiǎn)單了，只能將其體現(xiàn)的業(yè)務(wù)功能更加輕易可拓展了。

　　第二.在這個(gè)帖子中，作者舉了一個(gè)PacketParser業(yè)務(wù)案例，這段代碼是體現(xiàn)業(yè)務(wù)功能的，是一個(gè)數(shù)據(jù)包的分析，作者也比較了各種模式使用的不同，所以我們還是使用動(dòng)態(tài)代理模式或Command模式來(lái)消滅那些可能存在的if else

　　由以上兩個(gè)案例表明：業(yè)務(wù)邏輯是我們使用設(shè)計(jì)模式的切入點(diǎn)，而在分解業(yè)務(wù)邏輯時(shí)，我們習(xí)慣則可能使用if else來(lái)實(shí)現(xiàn)，當(dāng)你有這種企圖或者已經(jīng)實(shí)現(xiàn)代碼了，那么就應(yīng)該考慮是否需要重構(gòu)Refactoring了。

if else替代者

　　那么實(shí)戰(zhàn)中，哪些設(shè)計(jì)模式可以替代if else呢？其實(shí)GoF設(shè)計(jì)模式都可以用來(lái)替代if else，我們分別描述如下：

AOP或Decorator模式
　　
　　其實(shí)使用filter過(guò)濾器也可以替代我們業(yè)務(wù)中的if else，過(guò)濾器起到一種過(guò)濾和篩選作用，將符合本過(guò)濾器條件的對(duì)象攔截下來(lái)做某件事情，這就是一個(gè)過(guò)濾器的功能，多個(gè)過(guò)濾器組合在一起實(shí)際就是if else的組合。
　　所以，假如你實(shí)在想不出什么辦法，可以使用過(guò)濾器，將過(guò)濾器看成防火墻就比較好理解，當(dāng)客戶端有一個(gè)請(qǐng)求時(shí)，經(jīng)過(guò)不同性質(zhì)的防火墻，這個(gè)防火墻是攔截端口的；那個(gè)防火墻是安全檢查攔截等等。過(guò)濾器也如同紅藍(lán)白各種光濾鏡；紅色濾鏡只能將通過(guò)光線中的紅色攔截了；藍(lán)色濾鏡將光線中的藍(lán)色攔截下來(lái)，這實(shí)際上是對(duì)光線使用if else進(jìn)行分解。


　　如圖，通過(guò)一個(gè)個(gè)條件過(guò)濾器我們立體地實(shí)現(xiàn)了對(duì)信號(hào)的分離，假如你使用if else，說(shuō)明你是將圖中的條件1/2/3/4合并在一起，在同一個(gè)地方實(shí)現(xiàn)條件判定。
　　需要深入了解過(guò)濾器的實(shí)現(xiàn)細(xì)節(jié)和微小區(qū)別，請(qǐng)參考文章：AOP vs Decorator