C#實值型別和結構類型

    在向大家詳細介紹C#實值型別和C#結構類型之前，首先讓大家瞭解下類型設計，然後全面介紹C#實值型別和C#結構類型。

    條款討論的是類型設計時候的tradeoff——是將類型設計為結構還是類。Bill Wagner先生給出了一個原則“C#實值型別用於儲存資料，參考型別用於定義行為（value types store values and reference types define behavior）”。

    如何判斷這個原則的適用性，Bill Wagner也給出了一個方法，那就是首先回答下面幾個問題：
    1.該類型的主要職責是否用於資料存放區？
    2.該類型的公有介面是否都是一些存取屬性？
    3.是否確信該類型永遠不可能有子類？
    4.是否確信該類型永遠不可能具有多態行為？

    如果所有問題的答案都是yes，那麼就應該採用C#實值型別。這樣的判斷確實有很好的理由支撐，但是我個人認為“將這4個問題回答為yes”還不足以構成采 用C#實值型別的全部理由。因為在很多項目實踐中，我發現C#實值型別帶來的效能問題不可小視。C#實值型別帶來的效能問題主要有兩個：
    1.由於C#實值型別執行個體在棧和託管堆之間的轉換而導致的box/unbox，以及由此帶來的託管堆上的垃圾。
    2.C#實值型別預設情況下採用的是值拷貝語義，如果是比較大的C#實值型別，在傳遞參數和函數傳回值時，同樣會帶來效能問題。

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

    關於第2條，Scott Meyers先生在Effective C++的第22條“盡量使用pass-by-reference（傳址），少用pass-by-value（傳值）”中講的比較清楚。雖然由於C# C#結構類型具有預設的深拷貝語義，沒有拷貝構造器的調用。而且C#結構類型也沒有子類，因此在某種程度上來講不具有多態性，也就沒有C++對象傳值時可 能出現的切割（slicing）效應。但是值拷貝的成本仍然不小。尤其是在這個C#實值型別比較大的情況下，問題就比較嚴重。實際上，在.NET架構的 Design Guidelines for Class Library Developers文檔中，在說明什麼時候應該使用C#結構類型的時候，其中提到了一項原則（還有其他一些並行原則）——類型執行個體資料的大小要小於16 個位元組。該文檔主要是從類型的運行效率層面來考慮的，而Bill Wagner先生這裡的條款主要是從類型的設計層面來考慮的。

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