結構和類的區別

 

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

Bill Wagner 先生給了一個原則：

值類型用於存儲數據，引用類型用於定義行爲。

判斷第一個原則的適用性有以下四個問題

 

　    1.該類型的主要職責是否用於數據存儲？
　
　　2.該類型的公有接口是否都是一些存取屬性？

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

　　4.是否確信該類型永遠不可能具有多態行爲？

 

另一個原則應該是 值類型用於和非託管打交道，引用類型用於和託管打交道。

1.由於值類型實例在棧和託管堆之間的轉換而導致的box/unbox，以及由此帶來的託管堆上的垃圾。

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

第一條的解釋：

值類型的裝箱和取消裝箱過程中，

裝箱 生成了一個引用型的副本 造成託管堆上的垃圾

Bill Wagner在本條款中提到了“引用類型會給垃圾收集器帶來負擔”這個表面看似正確的判斷。但是由於box/unbox的效應，有些情況下，反倒是值類型給垃圾收集器帶來了更多的負擔。比如將一些值類型放到一個集合中，然後又頻繁地對其進行讀寫操作。如果碰到這種情況，我想“放棄結構而採用類”未嘗不是一種更好的做法。事實上，將一個用作數據存儲的值類型（比如System.Drawing.Point）添加到一個集合（System.Collections.ArrayList）中是一個太常見不過的操作。

第二條

 “儘量使用pass-by-reference（傳址），少用pass-by-value（傳值）”

在.NET框架的Design Guidelines for Class Library Developers文檔中，在說明什麼時候應該使用結構類型的時候，其中提到了一項原則（還有其他一些並行原則）——類型實例數據的大小要小於16個字節。該文檔主要是從類型的運行效率層面來考慮的

 

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