傳統思維習慣分析
為什么會業務邏輯層使用if else，其實使用者的目的也是為了重用，但是這是面向過程編程的重用，程序員只看到代碼重用，因為他看到if else幾種情況下大部分代碼都是重復的，只有個別不同，因此使用if else可以避免重復代碼，并且認為這是模板Template模式。
他范的錯誤是：程序員只從代碼運行順序這個方向來看待它的代碼，這種思維類似水管或串行電路，水沿著水管流動（代碼運行次序），當碰到幾個分管（子管），就分到這幾個分管子在流動，這里就相當于碰到代碼的if else處了。
而使用OO，則首先打破這個代碼由上向下順序等同于運行時的先后循序這個規律，代碼結構不由執行循序決定，由什么決定呢？由OO設計；設計模式會取代這些if else，但是最后總是由一個Service等總類按照運行順序組裝這些OO模塊，只有一處，這處可包含事務，一般就是Service，EJB中是session bean。
一旦需求變化，我們更多的可能是Service中各個OO模塊，甚至是只改動Service中的OO模塊執行順序就能符合需求。
這里我們也看到OO分離的思路，將以前過程語言的一個Main函數徹底分解，將運行順序與代碼其他邏輯分離開來，而不是象面向過程那樣混亂在一起。所以有人感慨，OO也是要順序的，這是肯定的，要害是運行順序要單獨分離出來。
是否有if else可以看出你有沒有將運行順序分離到家。
設計模式的切入口
經常有人反映，設計模式是不錯，但是我很難用到，其實假如你使用if else來寫代碼時（除顯示控制以外），就是在寫業務邏輯，只不過使用簡單的判定語句來作為現實情況的替代者。
還是以大家熟悉的論壇帖子為例子，如ForumMessage是一個模型，但是實際中帖子分兩種性質：主題貼（第一個根貼）和回帖（回以前帖子的帖子），這里有一個樸素的解決方案：
建立一個ForumMessage，然后在ForumMessage加入isTopic這樣判定語句，注重，你這里一個簡單屬性的判定引入，可能導致你的程序其他地方到處存在if else 的判定。
假如我們改用另外一種分析實現思路，以對象化概念看待，實際中有主題貼和回帖，就是兩種對象，但是這兩種對象大部分是一致的，因此，我將ForumMessage設為表達主題貼；然后創建一個繼續ForumMessage的子類ForumMessageReply作為回帖，這樣，我在程序地方，如Service中，我已經確定這個Model是回帖了，我就直接下溯為ForumMessageReply即可，這個有點類似向Collection放入對象和取出時的強制類型轉換。通過這個手段我消滅了以后程序中if else的判定語句出現可能。
從這里體現了，假如分析方向錯誤，也會導致誤用模式。
討論設計模式舉例，不能沒有業務上下文場景的案例，否則無法決定是否該用模式，下面舉兩個對比的例子：
第一. 這個帖子中舉例的第一個代碼案例是沒有上下文的，文中只說明有一段代碼：
main() {if（case A）{
//do with strategy A
}else(case B){
//do with strategy B
}else(case C){
//do with strategy C
}
}
這段代碼只是純粹的代碼，沒有業務功能，所以，在這種情況下，我們就很難確定使用什么模式，就是一定用策略模式等，也逃不過還是使用if else的命運，設計模式不是魔法，不能將一段毫無意義的代碼變得簡單了，只能將其體現的業務功能更加輕易可拓展了。
第二.在這個帖子中，作者舉了一個PacketParser業務案例，這段代碼是體現業務功能的，是一個數據包的分析，作者也比較了各種模式使用的不同，所以我們還是使用動態代理模式或Command模式來消滅那些可能存在的if else
由以上兩個案例表明：業務邏輯是我們使用設計模式的切入點，而在分解業務邏輯時，我們習慣則可能使用if else來實現，當你有這種企圖或者已經實現代碼了，那么就應該考慮是否需要重構Refactoring了。
if else替代者
那么實戰中，哪些設計模式可以替代if else呢？其實GoF設計模式都可以用來替代if else，我們分別描述如下：
public class Order{
PRivate int status;
//說明：
//status=1 表示訂貨但為查看 ；
//status=2 表示已經查看未處理；
//status=3 表示已經處理未付款
//status=4 表示已經付款未發貨
//status=5 表示已經發貨
}
新聞熱點
疑難解答
