| 以文本方式查看主題 - 曙海教育集團(tuán)論壇 (http://www.022-oo.cn/bbs/index.asp) -- Brew手機(jī)開(kāi)發(fā) (http://www.022-oo.cn/bbs/list.asp?boardid=49) ---- 深入brew開(kāi)發(fā):C#開(kāi)發(fā)的兩個(gè)原則的深入討論 (http://www.022-oo.cn/bbs/dispbbs.asp?boardid=49&id=2133) |
| -- 作者：wangxinxin -- 發(fā)布時(shí)間：2010-12-6 10:23:28 -- 深入brew開(kāi)發(fā):C#開(kāi)發(fā)的兩個(gè)原則的深入討論 使用屬性避免將數(shù)據(jù)成員直接暴露給外界 學(xué)習(xí)研究.NET早期經(jīng)常碰到些學(xué)習(xí)C#/.NET朋友問(wèn)要屬性這種華而不實(shí)東西做什么？后來(lái)做項(xiàng)目時(shí)也時(shí)常接到team里人抱怨反饋為什么不直接放個(gè)public字段？如: Card 而非要做個(gè)private字段+public屬性？ Card 我記得在早期個(gè)項(xiàng)目里team中個(gè)朋友甚至厭煩了寫(xiě)private字段+public屬性尤其是碰到大堆臃腫data object 時(shí)候索性自己寫(xiě)了個(gè)小工具來(lái)提供個(gè)類字段名和類型然后自動(dòng)為該類生成相應(yīng)private字段+public屬性 我在編程時(shí)候是個(gè)徹底實(shí)用主義者用稍微高雅點(diǎn)話說(shuō)叫“不喜歡過(guò)度設(shè)計(jì)”如果真像上面那樣寫(xiě)Card而且在將來(lái)沒(méi)有什么改變需求我也不喜歡像上面第2段那樣把事情故意搞得復(fù)雜但如果從component角度來(lái)講總有些是要供外部長(zhǎng)久地使用也潛在地在將來(lái)有被改變需求這時(shí)候提供屬性就很有必要了 這就是這個(gè)Item試圖要?dú)w納使用屬性理由: 1.可以對(duì)賦值做校驗(yàn)、或者額外處理 2.可以做線程同步 3.可以使用虛屬性、或者抽象屬性 4.可以將屬性置于erface中 5.可以提供get-only或者-only版本甚至可以給讀、寫(xiě)以區(qū)別訪問(wèn)權(quán)限(C# 2.0支持) 個(gè)人感覺(jué)3、4條是屬性最大優(yōu)點(diǎn)可以填補(bǔ)沒(méi)有“虛字段”或“抽象字段”缺憾在設(shè)計(jì)組件時(shí)候非常有用也體現(xiàn)了C#這樣component-oriented語(yǔ)言精神內(nèi)涵 但如果沒(méi)有上述理由而且日后對(duì)做大改動(dòng)可能性比較小時(shí)我想也大可不必非要把每個(gè)public字段都要變成屬性比如在設(shè)計(jì)些輕型struct用于互操作時(shí)候直接使用public字段沒(méi)什么不好所以感覺(jué)本條目Bill Wagner先生使用“Always Use Properties Instead of Accessible Data Members”顯得太過(guò)強(qiáng)硬 其實(shí)這里討論也表明閱讀Effective C#書(shū)時(shí)需要注意地方即Effective原則并不是放的 4海而皆準(zhǔn)區(qū)別項(xiàng)目(組件化、復(fù)用程度較高項(xiàng)目？還是“次編寫(xiě)、N年都run”項(xiàng)目)區(qū)別角色(類庫(kù)/組件開(kāi)發(fā)人員？還是應(yīng)用開(kāi)發(fā)人員？)有著區(qū)別Effective準(zhǔn)則事實(shí)上書(shū)中很多Items都是從類庫(kù)/組件開(kāi)發(fā)人員角度來(lái)考慮 有關(guān)屬性性能問(wèn)題需要談點(diǎn)如果僅僅是簡(jiǎn)單地以存取模式來(lái)使用屬性在相當(dāng)程度上是沒(méi)有性能損失在JIT編譯過(guò)程中已經(jīng)做了inline處理不過(guò)inline處理還是有些基本條件有些情況下JIT編譯器不會(huì)inline比如虛思路方法IL代碼長(zhǎng)度過(guò)長(zhǎng)(目前CLR規(guī)定是超過(guò)32s為代碼長(zhǎng)度過(guò)長(zhǎng))有復(fù)雜控制流邏輯有異常處理等這些條件都是要么根本不能使用inline(比如虛屬性)要么inline代價(jià)太大容易導(dǎo)致代碼bloat要么是inline起來(lái)很費(fèi)時(shí)間——已經(jīng)喪失了inline意義.NETinline機(jī)制發(fā)生在JIT過(guò)程中使用屬性有個(gè)別讓人感覺(jué)不舒服地方比如它影響開(kāi)發(fā)人員開(kāi)發(fā)效率但對(duì)代碼運(yùn)行效率不產(chǎn)生影響 明辨值類型和引用類型使用場(chǎng)合 這個(gè)條款討論是類型設(shè)計(jì)時(shí)候tradeoff——是將類型設(shè)計(jì)為結(jié)構(gòu)還是類Bill Wagner先生給出了個(gè)原則“值類型用于存儲(chǔ)數(shù)據(jù)引用類型用于定義行為(value types store values and reference types behavior)” 如何判斷這個(gè)原則適用性Bill Wagner也給出了個(gè)思路方法那就是首先回答下面幾個(gè)問(wèn)題: 1.該類型主要職責(zé)是否用于數(shù)據(jù)存儲(chǔ)？ 2.該類型公有接口是否都是些存取屬性？ 3.是否確信該類型永遠(yuǎn)不可能有子類？ 4.是否確信該類型永遠(yuǎn)不可能具有多態(tài)行為？ 如果所有問(wèn)題答案都是yes那么就應(yīng)該采用值類型這樣判斷確實(shí)有很好理由支撐但是我個(gè)人認(rèn)為“將這4個(gè)問(wèn)題回答為yes”還不足以構(gòu)成采用值類型全部理由在很多項(xiàng)目實(shí)戰(zhàn)中我發(fā)現(xiàn)值類型帶來(lái)性能問(wèn)題不可小視值類型帶來(lái)性能問(wèn)題主要有兩個(gè): 1.由于值類型例子在棧和托管堆的間轉(zhuǎn)換而導(dǎo)致box/unbox以及由此帶來(lái)托管堆上垃圾 2.值類型默認(rèn)情況下采用是值拷貝語(yǔ)義如果是比較大值類型在傳遞參數(shù)和返回值時(shí)同樣會(huì)帶來(lái)性能問(wèn)題 有關(guān)第1條Bill Wagner在本條款中提到了“引用類型會(huì)給垃圾收集器帶來(lái)負(fù)擔(dān)”這個(gè)表面看似正確判斷但是由于box/unbox效應(yīng)有些情況下反倒是值類型給垃圾收集器帶來(lái)了更多負(fù)擔(dān)比如將些值類型放到個(gè)集合中然后又頻繁地對(duì)其進(jìn)行讀寫(xiě)操作如果碰到這種情況我想“放棄結(jié)構(gòu)而采用類”未嘗不是種更好做法事實(shí)上將個(gè)用作數(shù)據(jù)存儲(chǔ)值類型(比如.Drawing.Po)添加到個(gè)集合(.Collections.ArrayList)中是個(gè)太常見(jiàn)不過(guò)操作不過(guò)C# 2.0中新引入泛型技術(shù)對(duì)box/unbox問(wèn)題有極大改善 有關(guān)第2條Scott Meyers先生在Effective C第22條“盡量使用pass-by-reference(傳址)少用pass-by-value(傳值)”中講比較清楚雖然由于C#中結(jié)構(gòu)類型具有默認(rèn)深拷貝語(yǔ)義沒(méi)有拷貝構(gòu)造器而且結(jié)構(gòu)類型也沒(méi)有子類因此在某種程度上來(lái)講不具有多態(tài)性也就沒(méi)有C對(duì)象傳值時(shí)可能出現(xiàn)切割(slicing)效應(yīng)但是值拷貝成本仍然不小尤其是在這個(gè)值類型比較大情況下問(wèn)題就比較嚴(yán)重實(shí)際上在.NET框架Design Guidelines for Class Library Developers文檔中在介紹說(shuō)明什么時(shí)候應(yīng)該使用結(jié)構(gòu)類型時(shí)候其中提到了項(xiàng)原則(還有其他些并行原則)——類型例子數(shù)據(jù)大小要小于16個(gè)字節(jié)該文檔主要是從類型運(yùn)行效率層面來(lái)考慮而B(niǎo)ill Wagner先生這里條款主要是從類型設(shè)計(jì)層面來(lái)考慮
從上述兩條討論來(lái)看我個(gè)人傾向于對(duì)結(jié)構(gòu)類型采取更為保守設(shè)計(jì)策略而對(duì)于類則可以積極大膽地使用“將結(jié)構(gòu)類型不適當(dāng)?shù)卦O(shè)計(jì)為類”帶來(lái)不良后果要遠(yuǎn)遠(yuǎn)小于“將類不適當(dāng)?shù)卦O(shè)計(jì)為結(jié)構(gòu)類型”所帶來(lái)不良后果就目前經(jīng)驗(yàn)來(lái)看我甚至認(rèn)為只有和非托管互操作打交道情況才是使用結(jié)構(gòu)類型最充足理由其他情況都要“ 3思而后行”當(dāng)然在C# 2.0中引入泛型技術(shù)的后box/unbox將不再是個(gè)沉重負(fù)擔(dān)應(yīng)付些非常輕量級(jí)場(chǎng)合結(jié)構(gòu)類型依然有自己席的地
|