面向過程設(shè)計和面向?qū)ο笤O(shè)計的主要區(qū)別是：是否在業(yè)務(wù)邏輯層使用冗長的if else判斷。如果你還在大量使用if else，當然，界面表現(xiàn)層除外，即使你使用Java/C#這樣完全面向?qū)ο蟮恼Z言，也只能說明你的思維停留在傳統(tǒng)的面向過程語言上。
傳統(tǒng)思維習慣分析
為什么會業(yè)務(wù)邏輯層使用if else，其實使用者的目的也是為了重用，但是這是面向過程編程的重用，程序員只看到代碼重用，因為他看到if else幾種情況下大部分代碼都是重復的，只有個別不同，因此使用if else可以避免重復代碼，并且認為這是模板Template模式。
他范的錯誤是：程序員只從代碼運行順序這個方向來看待它的代碼，這種思維類似水管或串行電路，水沿著水管流動（代碼運行次序），當遇到幾個分管（子管），就分到這幾個分管子在流動，這里就相當于碰到代碼的if else處了。
而使用OO，則首先打破這個代碼由上向下順序等同于運行時的先后循序這個規(guī)律，代碼結(jié)構(gòu)不由執(zhí)行循序決定，由什么決定呢？由OO設(shè)計；設(shè)計模式會取代這些if else，但是最后總是由一個Service等總類按照運行順序組裝這些OO模塊，只有一處，這處可包含事務(wù)，一般就是Service，EJB中是Session bean。
一旦需求變化，我們更多的可能是Service中各個OO模塊，甚至是只改動Service中的OO模塊執(zhí)行順序就能符合需求。
這里我們也看到OO分離的思路，將以前過程語言的一個Main函數(shù)徹底分解，將運行順序與代碼其他邏輯分離開來，而不是象面向過程那樣混亂在一起。所以有人感慨，OO也是要順序的，這是肯定的，關(guān)鍵是運行順序要單獨分離出來。
是否有if else可以看出你有沒有將運行順序分離到家。
設(shè)計模式的切入口
經(jīng)常有人反映，設(shè)計模式是不錯，但是我很難用到，其實如果你使用if else來寫代碼時（除顯示控制以外），就是在寫業(yè)務(wù)邏輯，只不過使用簡單的判斷語句來作為現(xiàn)實情況的替代者。
還是以大家熟悉的論壇帖子為例子，如ForumMessage是一個模型，但是實際中帖子分兩種性質(zhì)：主題貼（第一個根貼）和回帖（回以前帖子的帖子），這里有一個樸素的解決方案：
建立一個ForumMessage，然后在ForumMessage加入isTopic這樣判斷語句，注意，你這里一個簡單屬性的判斷引入，可能導致你的程序其他地方到處存在if else 的判斷。
如果我們改用另外一種分析實現(xiàn)思路，以對象化概念看待，實際中有主題貼和回帖，就是兩種對象，但是這兩種對象大部分是一致的，因此，我將ForumMessage設(shè)為表達主題貼；然后創(chuàng)建一個繼承ForumMessage的子類ForumMessageReply作為回帖，這樣，我在程序地方，如Service中，我已經(jīng)確定這個Model是回帖了，我就直接下溯為ForumMessageReply即可，這個有點類似向Collection放入對象和取出時的強制類型轉(zhuǎn)換。通過這個手段我消滅了以后程序中if else的判斷語句出現(xiàn)可能。
從這里體現(xiàn)了，如果分析方向錯誤，也會導致誤用模式。
討論設(shè)計模式舉例，不能沒有業(yè)務(wù)上下文場景的案例，否則無法決定是否該用模式，下面舉兩個對比的例子：
第一. 這個帖子中舉例的第一個代碼案例是沒有上下文的，文中只說明有一段代碼：
| main() {
if（case A）{ //do with strategy A }else(case B){ //do with strategy B }else(case C){ //do with strategy C } } | ? |
這段代碼只是純粹的代碼，沒有業(yè)務(wù)功能，所以，在這種情況下，我們就很難確定使用什么模式，就是一定用策略模式等，也逃不過還是使用if else的命運，設(shè)計模式不是魔法，不能將一段毫無意義的代碼變得簡單了，只能將其體現(xiàn)的業(yè)務(wù)功能更加容易可拓展了。
第二.在這個帖子中，作者舉了一個PacketParser業(yè)務(wù)案例，這段代碼是體現(xiàn)業(yè)務(wù)功能的，是一個數(shù)據(jù)包的分析，作者也比較了各種模式使用的不同，所以我們還是使用動態(tài)代理模式或Command模式來消滅那些可能存在的if else
由以上兩個案例表明：業(yè)務(wù)邏輯是我們使用設(shè)計模式的切入點，而在分解業(yè)務(wù)邏輯時，我們習慣則可能使用if else來實現(xiàn)，當你有這種企圖或者已經(jīng)實現(xiàn)代碼了，那么就應(yīng)該考慮是否需要重構(gòu)Refactoring了。
if else替代者
那么實戰(zhàn)中，哪些設(shè)計模式可以替代if else呢？其實GoF設(shè)計模式都可以用來替代if else，我們分別描述如下：
狀態(tài)模式
當數(shù)據(jù)對象存在各種可能性的狀態(tài)，而且這種狀態(tài)將會影響到不同業(yè)務(wù)結(jié)果時，那么我們就應(yīng)該考慮是否使用狀態(tài)模式，當然，使用狀態(tài)模式之前，你必須首先有內(nèi)存狀態(tài)這個概念，而不是數(shù)據(jù)庫概念，因為在傳統(tǒng)的面向過程的/面向數(shù)據(jù)庫的系統(tǒng)中，你很難發(fā)現(xiàn)狀態(tài)的，從數(shù)據(jù)庫中讀取某個值，然后根據(jù)這個值進行代碼運行分流，這是很多初學者常干的事情。參考文章:狀態(tài)對象：數(shù)據(jù)庫的替代者
使用傳統(tǒng)語言思維的情況還有：使用一個類整數(shù)變量標識狀態(tài)：
? public class Order{ private int status; //說明： //status=1 表示訂貨但為查看 ； //status=2 表示已經(jīng)查看未處理； //status=3 表示已經(jīng)處理未付款 //status=4 表示已經(jīng)付款未發(fā)貨 //status=5 表示已經(jīng)發(fā)貨 } |
上述類設(shè)計，無疑是將類作為傳統(tǒng)語言的函數(shù)來使用，這樣導致程序代碼中存在大量的if else。
策略模式
當你面臨幾種算法或者公式選擇時，可以考慮策略模式，傳統(tǒng)過程語言情況是：從數(shù)據(jù)庫中讀取算法數(shù)值，數(shù)值1表示策略1，例如保存到數(shù)據(jù)庫；數(shù)值為2表示策略2，例如保存到XMl文件中。這里使用if else作為策略選擇的開關(guān)。
command模式
傳統(tǒng)過程的思維情況是：如果客戶端發(fā)出代號是1或"A"，那么我調(diào)用A.java這個對象來處理；如果代號是2或"B"，我就調(diào)用B.java來處理，通過if else來判斷客戶端發(fā)送過來的代碼，然后按事先約定的對應(yīng)表，調(diào)用相應(yīng)的類來處理。
MVC模式
MVC模式的傳統(tǒng)語言誤用和Command模式類似，在一個Action類中，使用if else進行前后臺調(diào)度，如果客戶端傳送什么命令；我就調(diào)用后臺什么結(jié)果；如果后臺處理什么結(jié)構(gòu)，再決定推什么頁面，不過，現(xiàn)在我們使用Struts/JSF這樣MVC模式的框架實現(xiàn)者就不必范這種低級錯誤。
職責鏈模式
職責鏈模式和Command模式是可選的，如果你實在不知道客戶端會發(fā)出什么代號；也沒有一個事先定義好的對照表，那么你只能編寫一個個類去碰運氣一樣打開這個包看一下就可以。與Command是不同在AOP vs Decorator一文中有分析。
代理或動態(tài)代理模式
代理對象可以是符合某種條件的代表者，比如，權(quán)限檢驗，傳統(tǒng)面向過程思維是：當一個用戶登陸后，訪問某資源時，使用if else進行判斷，只有某種條件符合時，才能允許訪問，這樣權(quán)限判斷和業(yè)務(wù)數(shù)據(jù)邏輯混亂在一起，使用代理模式可以清晰分離，如果嫌不太好，使用動態(tài)代理，或者下面AOP等方式。
AOP或Decorator模式
其實使用filter過濾器也可以替代我們業(yè)務(wù)中的if else，過濾器起到一種過濾和篩選作用，將符合本過濾器條件的對象攔截下來做某件事情，這就是一個過濾器的功能，多個過濾器組合在一起實際就是if else的組合。
所以，如果你實在想不出什么辦法，可以使用過濾器，將過濾器看成防火墻就比較好理解，當客戶端有一個請求時，經(jīng)過不同性質(zhì)的防火墻，這個防火墻是攔截端口的；那個防火墻是安全檢查攔截等等。過濾器也如同紅藍白各種光濾鏡；紅色濾鏡只能將通過光線中的紅色攔截了；藍色濾鏡將光線中的藍色攔截下來，這實際上是對光線使用if else進行分解。
如圖，通過一個個條件過濾器我們立體地實現(xiàn)了對信號的分離，如果你使用if else，說明你是將圖中的條件1/2/3/4合并在一起，在同一個地方實現(xiàn)條件判斷。
需要深入了解過濾器的實現(xiàn)細節(jié)和微小區(qū)別，請參考文章：AOP vs Decorator
OO設(shè)計的總結(jié)
還有一種偽模式，雖然使用了狀態(tài)等模式，但是在模式內(nèi)部實質(zhì)還是使用if else或switch進行狀態(tài)切換或重要條件判斷，那么無疑說明還需要進一步努力。更重要的是，不能以模式自居，而且出書示人。
真正掌握面向?qū)ο筮@些思想是一件困難的事情，目前有各種屬于揪著自己頭發(fā)向上拔的解說，都是誤人子弟的，所以我覺得初學者讀Thinking in Java（Java編程思想）是沒有用，它試圖從語言層次來講OO編程思想，非常失敗，作為語言參考書可以，但是作為Java體現(xiàn)的OO思想的學習資料，就錯了。
OO編程思想是一種方法論，方法論如果沒有應(yīng)用比較，是無法體會這個方法論的特點的，禪是古代一個方法論，悟禪是靠挑水砍柴這些應(yīng)用才能體會。
那么OO思想靠什么應(yīng)用能夠體會到了？是GoF設(shè)計模式，GoF設(shè)計模式是等于軟件人員的挑水砍柴等基本活，所以，如果一個程序員連基本活都不會，他何以自居OO程序員？從事OO專業(yè)設(shè)計編程這個工作，如果不掌握設(shè)計模式基本功，就象一個做和尚的人不愿意挑水砍柴，他何以立足這個行業(yè)？早就被師傅趕下山。
最后總結(jié)：將if else用在小地方還可以，如簡單的數(shù)值判斷；但是如果按照你的傳統(tǒng)習慣思維，在實現(xiàn)業(yè)務(wù)功能時也使用if else，那么說明你的思維可能需要重塑，你的編程經(jīng)驗越豐富，傳統(tǒng)過程思維模式就容易根深蒂固，想靠自己改變很困難；建議接受專業(yè)頭腦風暴培訓。
用一句話總結(jié)：如果你做了不少系統(tǒng)，很久沒有使用if else了，那么說明你可能真正進入OO設(shè)計的境地了。（這是本人自己發(fā)明的實戰(zhàn)性的衡量考核標準）。
轉(zhuǎn)自 : 板橋里人 http://www.jdon.com 2006/1/11