使用屬性，避免將數(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è)朋友甚至厭煩了寫private字段+public屬性，尤其是碰到一大堆臃腫的data object class的時(shí)候，索性自己寫了一個(gè)小工具，來(lái)提供一個(gè)類的字段名和類型，然后自動(dòng)為該類生成相應(yīng)的private字段+public屬性。

　　我在編程的時(shí)候是個(gè)徹底的實(shí)用主義者，用稍微高雅一點(diǎn)的話說(shuō)叫“不喜歡過(guò)度的設(shè)計(jì)”。如果真的像上面那樣寫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版本，甚至可以給讀、寫以不同的訪問(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í)需要注意的地方，即Effective原則并不是放之四海而皆準(zhǔn)的。不同的項(xiàng)目（組件化、復(fù)用程度較高的項(xiàng)目？還是“一次編寫、N年都run”的項(xiàng)目），不同的角色（類庫(kù)/組件開(kāi)發(fā)人員？還是應(yīng)用程序開(kāi)發(fā)人員？），有著不同的Effective準(zhǔn)則。事實(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)生影響。

　　明辨值類型和引用類型的使用場(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 define 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)成采用值類型的全部理由。因?yàn)樵诤芏囗?xiàng)目實(shí)踐中，我發(fā)現(xiàn)值類型帶來(lái)的性能問(wèn)題不可小視。值類型帶來(lái)的性能問(wèn)題主要有兩個(gè)：

　　1.由于值類型實(shí)例在棧和托管堆之間的轉(zhuǎn)換而導(dǎo)致的box/unbox，以及由此帶來(lái)的托管堆上的垃圾。

　　2.值類型默認(rèn)情況下采用的是值拷貝語(yǔ)義，如果是比較大的值類型，在傳遞參數(shù)和函數(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)行讀寫操作。如果碰到這種情況，我想“放棄結(jié)構(gòu)而采用類”未嘗不是一種更好的做法。事實(shí)上，將一個(gè)用作數(shù)據(jù)存儲(chǔ)的值類型（比如System.Drawing.Point）添加到一個(gè)集合（System.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)造器的調(diào)用。而且結(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í)例數(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ì)于類則可以積極大膽地使用。因?yàn)椤皩⒔Y(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)類型最充足的理由，其他情況都要“三思而后行”。當(dāng)然，在C# 2.0中引入泛型技術(shù)之后，box/unbox將不再是一個(gè)沉重的負(fù)擔(dān)，應(yīng)付一些非常輕量級(jí)的場(chǎng)合，結(jié)構(gòu)類型依然有自己的一席之地