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字段?如：

　　class Card

　　{ public string Name;}

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

　　class Card

　　{

　　private string name;

　　public string Name{

　　get { return this.name;}

　　set { this.name=value;}}

　　}

　　我記得在早期的一個(gè)項(xiàng)目里，team中的一個(gè)朋友甚至厭煩了寫(xiě)private字段+public屬性，尤其是碰到一大堆臃腫的data object class的時(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)講，總有一些class是要供外部長(zhǎng)久地使用，也潛在地在將來(lái)有被改變的需求。這時(shí)候，提供屬性就很有必要了。

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

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

　　2、可以做線程同步

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

　　4、可以將屬性置于interface中

　　5、可以提供get-only或者set-only版本，甚至可以給讀、寫(xiě)以不同的訪問(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原則并不是放之四海而皆準(zhǔn)的。不同的項(xiàng)目(組件化、復(fù)用程度較高的項(xiàng)目?還是“一次編寫(xiě)、N年都run”的項(xiàng)目)，不同的角色(類庫(kù)/組件開(kāi)發(fā)人員?還是應(yīng)用程序開(kāi)發(fā)人員?)，有著不同的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)有性能損失的。因?yàn)樵贘IT編譯過(guò)程中已經(jīng)做了inline的處理。不過(guò)inline處理還是有一些基本的條件，有些情況下JIT編譯器不會(huì)inline，比如虛調(diào)用，方法的IL代碼長(zhǎng)度過(guò)長(zhǎng)(目前CLR的規(guī)定是超過(guò)32bytes為代碼長(zhǎng)度過(guò)長(zhǎng))，有復(fù)雜的控制流邏輯，有異常處理等。這些條件都是要么根本不能使用inline(比如虛屬性)，要么inline的代價(jià)太大，容易導(dǎo)致代碼的bloat，要么是inline起來(lái)很費(fèi)時(shí)間——已經(jīng)喪失了inline的意義，因?yàn)?NET的inline機(jī)制發(fā)生在JIT過(guò)程中。使用屬性有個(gè)別讓人感覺(jué)不舒服的地方，比如它影響開(kāi)發(fā)人員的開(kāi)發(fā)效率，但對(duì)代碼運(yùn)行的效率不產(chǎn)生影響。