使用屬性避免將數(shù)據(jù)成員直接暴露給外界

　　學(xué)習(xí)研究.NET早期經(jīng)常碰到些學(xué)習(xí)C#/.NET朋友問要屬性這種華而不實(shí)東西做什么？后來做項(xiàng)目時(shí)也時(shí)常接到team里人抱怨反饋為什么不直接放個(gè)public字段？如:

　　 Card
{
　public  Name;
}

　　而非要做個(gè)private字段+public屬性？

　　 Card
{
　private  name;
　public  Name
　{
　　get {  this.name;}
　　 { this.name=value;}
　}
}

　　我記得在早期個(gè)項(xiàng)目里team中個(gè)朋友甚至厭煩了寫private字段+public屬性尤其是碰到大堆臃腫data object 時(shí)候索性自己寫了個(gè)小工具來提供個(gè)類字段名和類型然后自動為該類生成相應(yīng)private字段+public屬性

　　我在編程時(shí)候是個(gè)徹底實(shí)用主義者用稍微高雅點(diǎn)話說叫“不喜歡過度設(shè)計(jì)”如果真像上面那樣寫Card而且在將來沒有什么改變需求我也不喜歡像上面第2段那樣把事情故意搞得復(fù)雜但如果從component角度來講總有些是要供外部長久地使用也潛在地在將來有被改變需求這時(shí)候提供屬性就很有必要了

　　這就是這個(gè)Item試圖要?dú)w納使用屬性理由:

　　1.可以對賦值做校驗(yàn)、或者額外處理

　　2.可以做線程同步

　　3.可以使用虛屬性、或者抽象屬性

　　4.可以將屬性置于erface中

　　5.可以提供get-only或者-only版本甚至可以給讀、寫以區(qū)別訪問權(quán)限(C# 2.0支持)

　　個(gè)人感覺3、4條是屬性最大優(yōu)點(diǎn)可以填補(bǔ)沒有“虛字段”或“抽象字段”缺憾在設(shè)計(jì)組件時(shí)候非常有用也體現(xiàn)了C#這樣component-oriented語言精神內(nèi)涵

　　但如果沒有上述理由而且日后對做大改動可能性比較小時(shí)我想也大可不必非要把每個(gè)public字段都要變成屬性比如在設(shè)計(jì)些輕型struct用于互操作時(shí)候直接使用public字段沒什么不好所以感覺本條目Bill Wagner先生使用“Always Use Properties Instead of Accessible Data Members”顯得太過強(qiáng)硬

　　其實(shí)這里討論也表明閱讀Effective C#書時(shí)需要注意地方即Effective原則并不是放的 4海而皆準(zhǔn)區(qū)別項(xiàng)目(組件化、復(fù)用程度較高項(xiàng)目？還是“次編寫、N年都run”項(xiàng)目)區(qū)別角色(類庫/組件開發(fā)人員？還是應(yīng)用開發(fā)人員？)有著區(qū)別Effective準(zhǔn)則事實(shí)上書中很多Items都是從類庫/組件開發(fā)人員角度來考慮

　　有關(guān)屬性性能問題需要談點(diǎn)如果僅僅是簡單地以存取模式來使用屬性在相當(dāng)程度上是沒有性能損失在JIT編譯過程中已經(jīng)做了inline處理不過inline處理還是有些基本條件有些情況下JIT編譯器不會inline比如虛思路方法IL代碼長度過長(目前CLR規(guī)定是超過32s為代碼長度過長)有復(fù)雜控制流邏輯有異常處理等這些條件都是要么根本不能使用inline(比如虛屬性)要么inline代價(jià)太大容易導(dǎo)致代碼bloat要么是inline起來很費(fèi)時(shí)間——已經(jīng)喪失了inline意義.NETinline機(jī)制發(fā)生在JIT過程中使用屬性有個(gè)別讓人感覺不舒服地方比如它影響開發(fā)人員開發(fā)效率但對代碼運(yùn)行效率不產(chǎn)生影響

　　明辨值類型和引用類型使用場合

　　這個(gè)條款討論是類型設(shè)計(jì)時(shí)候tradeoff——是將類型設(shè)計(jì)為結(jié)構(gòu)還是類Bill Wagner先生給出了個(gè)原則“值類型用于存儲數(shù)據(jù)引用類型用于定義行為(value types store values and reference types  behavior)”

　　如何判斷這個(gè)原則適用性Bill Wagner也給出了個(gè)思路方法那就是首先回答下面幾個(gè)問題:

　　1.該類型主要職責(zé)是否用于數(shù)據(jù)存儲？

　　2.該類型公有接口是否都是些存取屬性？

　　3.是否確信該類型永遠(yuǎn)不可能有子類？

　　4.是否確信該類型永遠(yuǎn)不可能具有多態(tài)行為？

　　如果所有問題答案都是yes那么就應(yīng)該采用值類型這樣判斷確實(shí)有很好理由支撐但是我個(gè)人認(rèn)為“將這4個(gè)問題回答為yes”還不足以構(gòu)成采用值類型全部理由在很多項(xiàng)目實(shí)戰(zhàn)中我發(fā)現(xiàn)值類型帶來性能問題不可小視值類型帶來性能問題主要有兩個(gè):

　　1.由于值類型例子在棧和托管堆的間轉(zhuǎn)換而導(dǎo)致box/unbox以及由此帶來托管堆上垃圾

　　2.值類型默認(rèn)情況下采用是值拷貝語義如果是比較大值類型在傳遞參數(shù)和返回值時(shí)同樣會帶來性能問題

　　有關(guān)第1條Bill Wagner在本條款中提到了“引用類型會給垃圾收集器帶來負(fù)擔(dān)”這個(gè)表面看似正確判斷但是由于box/unbox效應(yīng)有些情況下反倒是值類型給垃圾收集器帶來了更多負(fù)擔(dān)比如將些值類型放到個(gè)集合中然后又頻繁地對其進(jìn)行讀寫操作如果碰到這種情況我想“放棄結(jié)構(gòu)而采用類”未嘗不是種更好做法事實(shí)上將個(gè)用作數(shù)據(jù)存儲值類型(比如.Drawing.Po)添加到個(gè)集合(.Collections.ArrayList)中是個(gè)太常見不過操作不過C# 2.0中新引入泛型技術(shù)對box/unbox問題有極大改善

　　有關(guān)第2條Scott Meyers先生在Effective C第22條“盡量使用pass-by-reference(傳址)少用pass-by-value(傳值)”中講比較清楚雖然由于C#中結(jié)構(gòu)類型具有默認(rèn)深拷貝語義沒有拷貝構(gòu)造器而且結(jié)構(gòu)類型也沒有子類因此在某種程度上來講不具有多態(tài)性也就沒有C對象傳值時(shí)可能出現(xiàn)切割(slicing)效應(yīng)但是值拷貝成本仍然不小尤其是在這個(gè)值類型比較大情況下問題就比較嚴(yán)重實(shí)際上在.NET框架Design Guidelines for Class Library Developers文檔中在介紹說明什么時(shí)候應(yīng)該使用結(jié)構(gòu)類型時(shí)候其中提到了項(xiàng)原則(還有其他些并行原則)——類型例子數(shù)據(jù)大小要小于16個(gè)字節(jié)該文檔主要是從類型運(yùn)行效率層面來考慮而Bill Wagner先生這里條款主要是從類型設(shè)計(jì)層面來考慮

 

　　從上述兩條討論來看我個(gè)人傾向于對結(jié)構(gòu)類型采取更為保守設(shè)計(jì)策略而對于類則可以積極大膽地使用“將結(jié)構(gòu)類型不適當(dāng)?shù)卦O(shè)計(jì)為類”帶來不良后果要遠(yuǎn)遠(yuǎn)小于“將類不適當(dāng)?shù)卦O(shè)計(jì)為結(jié)構(gòu)類型”所帶來不良后果就目前經(jīng)驗(yàn)來看我甚至認(rèn)為只有和非托管互操作打交道情況才是使用結(jié)構(gòu)類型最充足理由其他情況都要“ 3思而后行”當(dāng)然在C# 2.0中引入泛型技術(shù)的后box/unbox將不再是個(gè)沉重負(fù)擔(dān)應(yīng)付些非常輕量級場合結(jié)構(gòu)類型依然有自己席的地