C#開發(fā)中的兩個基本原則是：

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

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

　　class Card

　　{ public string Name;}

　　而要做一個private字段+public屬性

　　class Card

　　{

　　private string name;

　　public string Name{

　　get { return this.name;}

　　set { this.name=value;}}

　　}

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

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

　　這就是這個Item試圖要?dú)w納的使用屬性的理由：

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

　　2、可以做線程同步

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

　　4、可以將屬性置于interface中

　　5、可以提供get-only或者set-only版本，甚至可以給讀、寫以不同的訪問權(quán)限(C# 2.0支持)

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

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

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

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