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