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

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

　　 Card
{
　public  Name;
}

　　而非要做個private字段+public屬性？

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

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

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

　　這就是這個Item試圖要歸納使用屬性理由:

　　1.可以對賦值做校驗、或者額外處理

　　2.可以做線程同步

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

　　4.可以將屬性置于erface中

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

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

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

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

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

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

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

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

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

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

　　3.是否確信該類型永遠不可能有子類？

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

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

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

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

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

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

 

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