使用面向?qū)ο蟮脑O(shè)計(jì)方法，可以產(chǎn)生很棒的設(shè)計(jì)，但也很容易搞出很糟糕的設(shè)計(jì).為了更好地使用面向?qū)ο蟮姆椒?，來聽一下反對者的聲音?div style="height:15px;">
Stephen C Johnson: 面向?qū)ο蟮哪Ｐ褪沟梦覀兛梢杂镁凵俪啥嗟姆椒▉韺懗绦颉＿@通常是說，它提供了一種用結(jié)構(gòu)化的方法寫出爛面條般程序的方法。
一般觀點(diǎn)認(rèn)為，面向?qū)ο笤O(shè)計(jì)方法比傳統(tǒng)的結(jié)構(gòu)化設(shè)計(jì)方法要好。對象是“更好的模塊”，他把屬性和方法放在了一起，使用少量的接口對內(nèi)部信息進(jìn)行封裝。但對象確實(shí)是“更難把握的模塊”。面向?qū)ο笥袝r(shí)候?yàn)閴牡脑O(shè)計(jì)提供了一個(gè)好的理由。當(dāng)前有些反對面向?qū)ο蟮穆曇簦褪且驗(yàn)榇?。面向?qū)ο蟮脑O(shè)計(jì)方法優(yōu)點(diǎn)和缺點(diǎn)都十分突出的，也許是因?yàn)樵綇?qiáng)大的東西越難以掌握吧。要更好地使用面向?qū)ο蟊仨毩私饷嫦驅(qū)ο蟮娜秉c(diǎn)。
為了解公司軟件的開發(fā)質(zhì)量，最近做了許多代碼閱讀的工作。終結(jié)了一些面向?qū)ο蟪７傅腻e(cuò)誤。
面向?qū)ο鬄槿肿兞哭q護(hù)
大家都知道使用全局變量是糟糕的 設(shè)計(jì)，因?yàn)槿肿兞繋砹诉^分地耦合，應(yīng)該盡量的避免。許多初學(xué)者，在使用面向?qū)ο蟮恼Z言之后，喜歡把設(shè)計(jì)出的全局變量，封裝在一個(gè)對象里面，在定義幾個(gè) 接口函數(shù)對這些全局變量訪問，這時(shí)全局變量好像消失了。甚至，一些對見多識廣的程序員，這時(shí)會使用單件模式，把一個(gè)或多個(gè)全局變量放到一個(gè)全局唯一的對象 中。沒有了全局變量，程序員心安理得，甚至為自己使用了設(shè)計(jì)模式而驕傲?？墒侨肿兞科鋵?shí)沒用消失，而是使用一個(gè)“單件對象”的面目把自己隱藏起來，他所 帶來的過分耦合沒用消失，甚至是加重了：如果你把幾個(gè)無關(guān)的全局變量封裝到了一起，原來共享一個(gè)全局變量的模塊，現(xiàn)在要和更多的模塊共享這個(gè)全局對象。
過度使用膠水層封裝別人的代碼
在代碼中我發(fā)現(xiàn)，有許多helper形式的類。在多個(gè)人開發(fā)的項(xiàng)目中，許多程序員不喜歡直接使用別人提供的接口。而 是按照自己的調(diào)用習(xí)慣進(jìn)行封裝。甚至常常創(chuàng)建一套新的邏輯來封裝舊的邏輯，甚至創(chuàng)造更復(fù)雜的邏輯來隱藏一個(gè)簡單的邏輯。結(jié)果這個(gè)厚厚的膠水層，增加了整個(gè) 系統(tǒng)的復(fù)雜度,特別是增加了debuging的難度。程序員很可能是擔(dān)心別人的東西發(fā)生變化，而使用這個(gè)膠水層把自己保護(hù)起來，希望：萬一別人發(fā)生變化， 自己只修改這個(gè)膠水層就可以了。往往實(shí)際的效果是：因?yàn)檫@個(gè)膠水層要調(diào)和雙方的邏輯，當(dāng)發(fā)生變化時(shí)，不太容易修改它。在傳統(tǒng)的面向過程的語言中，這種情況 就相對較少，傳統(tǒng)的語言更鼓勵(lì)對別人的函數(shù)進(jìn)行簡單和直接地調(diào)用。
所有的基類都定義成虛類（或接口）
“接口與實(shí)現(xiàn)分離”，程序員一但掌握便開始堅(jiān)信的哲學(xué)。“要為未來變化準(zhǔn)備好”，將來我可以在不改變接口的情況下， 添加一個(gè)子類實(shí)現(xiàn)，而對其他模塊不產(chǎn)生影響。其實(shí)，基類還是是實(shí)現(xiàn)子類公共行為的地方。把子類的公共邏輯放到基類里面，子類就不需要重復(fù)實(shí)現(xiàn)這些邏輯。這 樣對未來準(zhǔn)備得更好，當(dāng)添加一個(gè)新的子類實(shí)現(xiàn)時(shí),你不需要重復(fù)實(shí)現(xiàn)已經(jīng)有的功能。
舉個(gè)例子：
設(shè)計(jì)一個(gè)類ConfigInfo，其對象保存程序需要的配置信息。設(shè)計(jì)合適的數(shù)據(jù)結(jié)構(gòu)，對象aConfigInfo把配置信息從外部的存儲介質(zhì)加載到內(nèi)存中。
其他模塊就可以通過aConfigInfo提供的接口訪問這些配置信息。
當(dāng)接受到配置信息更新信號時(shí)，發(fā)“重新加載”的消息給aConfigTable。
存儲配置信息的存儲介質(zhì)可能是文本文件，也可能來自數(shù)據(jù)庫中。分別使用兩個(gè)子類實(shí)現(xiàn)：ConfigDbImp和ConfigFileImp。
如果把ConfigInfo定義成接口，ConfigDbImp和ConfigFileImp會重復(fù)實(shí)現(xiàn)存儲配置信息的數(shù)據(jù)結(jié)構(gòu)，重復(fù)實(shí)現(xiàn)內(nèi)存中配置信息的訪問接口，兩個(gè)子類會有許多相似的代碼。如果這些行為都交給父類實(shí)現(xiàn)，每個(gè)子類就可以只重寫一個(gè)load()操作：把配置信息從外部的存儲介質(zhì)加載到內(nèi)存。另外，如果這個(gè)東東用在多線程環(huán)境，線程同步的所有邏輯也可以交給基類ConfigInfo實(shí)現(xiàn)。如果將來出現(xiàn)了一個(gè)新的配置文件格式，只需要定義一個(gè)新子類并重寫load操作。
（未完待續(xù)）
發(fā)表于： 2007-12-30，修改于： 2008-01-03 13:11 已瀏覽536次，有評論5條
推薦投訴網(wǎng)友評論
本站網(wǎng)友 時(shí)間：2007-12-30 23:42:33 IP地址：221.221.95.★
第一種我也見到很多類似的壞設(shè)計(jì)（包括寫過），耦合性太強(qiáng)、測試沒法簡單進(jìn)行。每個(gè)對象（模塊）的變量還是隔離在這個(gè)模塊內(nèi)好。這方面有個(gè)例子，spring依賴注入機(jī)制動(dòng)態(tài)注入而不耦合。
第二種必須要隔離，有適配器或代理模式。
面向?qū)ο笤O(shè)計(jì)確實(shí)不好把握，更容易產(chǎn)生讓人迷惑的東西。
cuichaox 時(shí)間：2007-12-31 12:54:00 IP地址：124.64.6.★
嗯.有空了解一下你說的“動(dòng)態(tài)注入”。
個(gè)人認(rèn)為,已經(jīng)存在的雙方接口不兼容的時(shí)候才使用adapter模式。如果任一方是從重零開始設(shè)計(jì)(許多情況下雙方都是從零開始的)，應(yīng)該盡量避免厚的膠水。而代理模式主要用來控制被代理對象的訪問。
許多情況，是對平衡的把握。有時(shí)候，那些優(yōu)美的方法使用過度了：本來是解決方案的一部分，最后成為了問題的一部分。
本站網(wǎng)友 時(shí)間：2008-01-02 10:57:51 IP地址：219.145.57.★
額,,, 確實(shí)經(jīng)常有helper
fera 時(shí)間：2008-01-04 11:04:13 IP地址：202.96.60.★
其實(shí)糟糕的設(shè)計(jì)來自于懶惰和對應(yīng)用領(lǐng)域的背景知識不了解導(dǎo)致的，并不是由面向?qū)ο蠓椒◣淼摹O的本質(zhì)是識別和組織應(yīng)用領(lǐng)域地概念，但是有多少人能夠“完美”地掌握這些概念并對概念進(jìn)行分組？例如window窗體類的設(shè)計(jì)，相信會有很多不同的設(shè)計(jì)，這是因?yàn)榇蠹已壑锌匆姷母拍罨ゲ幌嗤?div style="height:15px;">
（1）這篇文章并非在批評“面向?qū)ο?#8221;（2）我日常就是使用面向?qū)ο蟮脑O(shè)計(jì)方法。（3）如文章開頭所說，“面向?qū)ο?#8221;可以產(chǎn)生很棒的設(shè)計(jì)。（4）我整理的這些：人在面向使用對象時(shí)，容易犯的錯(cuò)誤。因?yàn)槲艺J(rèn)為，了解這些錯(cuò)誤對更好的使用面向?qū)ο蠛苡幸饬x。（5）要用好一個(gè)東西，必須了解它的缺點(diǎn)的一面。面向?qū)ο蟮姆椒y以掌握，正因?yàn)檫@個(gè)缺點(diǎn)，所以更容易犯錯(cuò)誤。為了掌握它，必須了解這些。
好的設(shè)計(jì)會來自“懶惰”，也會來自過于”勤奮“，不曉得簡化和重用的勤快人很多。---應(yīng)該這樣概況：好的設(shè)計(jì)人員腦勤手懶，差的程序員手勤腦懶。
對應(yīng)用領(lǐng)域的理解肯定是必要的，這是必要條件，這很對。這讓我想起來另外一個(gè)情況：人都寄希望與在應(yīng)用領(lǐng)域直接抽象出概念，構(gòu)造對象模型，面向?qū)ο蟮脑O(shè)計(jì)方法，也是這樣講的?？墒牵翰⒎撬械念I(lǐng)域都能直接抽象出對象。面向?qū)ο蟮姆椒ㄔ谌齻€(gè)領(lǐng)域最為成功（計(jì)算機(jī)圖形，GUI和模擬現(xiàn)實(shí)）。因?yàn)檫@三個(gè)領(lǐng)域能容易抽象出模型，而其他其他領(lǐng)域，并沒有像人們開始想象地那樣能直接地尋找到對象（這個(gè)說法來自《UNIX編程的藝術(shù)》）。
這樣的領(lǐng)域中，更多的概念來自設(shè)計(jì)人員的“發(fā)明”而不是“發(fā)現(xiàn)”。這類領(lǐng)域的對象建模隨意性大，更難以掌握。你舉的window的例子屬于GUI領(lǐng)域，已經(jīng)算是容易統(tǒng)一的概念了。你尚且認(rèn)為：“大家眼中的概念互補(bǔ)相同”?？梢妼ο蠼Ｖy度。
