你還在用if else嗎
面向過程設計和麵向物件設計的主要區別是：是否在業務邏輯層使用冗長的if else判斷。如果你還在大量使用if else，當然，介面表現層除外，即使你使用Java/C#這樣完全面向物件的語言，也只能說明你的思維停留在傳統的面向過程語言上。
傳統思維習慣分析
為什麼會業務邏輯層使用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 表示已經發貨 } |
如圖，通過一個個條件過濾器我們立體地實現了對訊號的分離，如果你使用if else，說明你是將圖中的條件1/2/3/4合併在一起，在同一個地方實現條件判斷。 需要深入瞭解過濾器的實現細節和微小區別，請參考文章：AOP vs DecoratorOO設計的總結
還有一種偽模式，雖然使用了狀態等模式，但是在模式內部實質還是使用if else或switch進行狀態切換或重要條件判斷，那麼無疑說明還需要進一步努力。更重要的是，不能以模式自居，而且出書示人。
真正掌握面向物件這些思想是一件困難的事情，目前有各種屬於揪著自己頭髮向上拔的解說，都是誤人子弟的，所以我覺得初學者讀Thinking in Java（Java程式設計思想）是沒有用，它試圖從語言層次來講OO程式設計思想，非常失敗，作為語言參考書可以，但是作為Java體現的OO思想的學習資料，就錯了。
OO程式設計思想是一種方法論，方法論如果沒有應用比較，是無法體會這個方法論的特點的，禪是古代一個方法論，悟禪是靠挑水砍柴這些應用才能體會。
那麼OO思想靠什麼應用能夠體會到了？是GoF設計模式，GoF設計模式是等於軟體人員的挑水砍柴等基本活，所以，如果一個程式設計師連基本活都不會，他何以自居OO程式設計師？從事OO專業設計程式設計這個工作，如果不掌握設計模式基本功，就象一個做和尚的人不願意挑水砍柴，他何以立足這個行業？早就被師傅趕下山。
最後總結：將if else用在小地方還可以，如簡單的數值判斷；但是如果按照你的傳統習慣思維，在實現業務功能時也使用if else，那麼說明你的思維可能需要重塑，你的程式設計經驗越豐富，傳統過程思維模式就容易根深蒂固，想靠自己改變很困難；建議接受專業頭腦風暴培訓。
用一句話總結：如果你做了不少系統，很久沒有使用if else了，那麼說明你可能真正進入OO設計的境地了。（這是本人自己發明的實戰性的衡量考核標準）。
轉自：http://www.jdon.com 2006/1/11