使用屬性避免將數據成員直接暴露給外界
學習研究NET的早期經常碰到一些學習C#/NET的朋友問要屬性這種華而不實的東西做什麼？後來做項目時也時常接到team裡的人的抱怨反饋為什麼不直接放一個public字段？如
class Card
{
public string Name;
}
而非要做一個private字段+public屬性？
class Card
{
private string name;
public string Name
{
get { return thisname;}
set { thisname=value;}
}
}
我記得在早期的一個項目裡team中的一個朋友甚至厭煩了寫private字段+public屬性尤其是碰到一大堆臃腫的data object class的時候索性自己寫了一個小工具來提供一個類的字段名和類型然後自動為該類生成相應的private字段+public屬性
我在編程的時候是個徹底的實用主義者用稍微高雅一點的話說叫不喜歡過度的設計如果真的像上面那樣寫Card而且在將來沒有什麼改變的需求我也不喜歡像上面第段程序那樣把事情故意搞得復雜但如果從component的角度來講總有一些class是要供外部長久地使用也潛在地在將來有被改變的需求這時候提供屬性就很有必要了
這就是這個Item試圖要歸納的使用屬性的理由
可以對賦值做校驗或者額外的處理
可以做線程同步
可以使用虛屬性或者抽象屬性
可以將屬性置於interface中
可以提供getonly或者setonly版本甚至可以給讀寫以不同的訪問權限（C# 支持）
個人感覺條是屬性最大的優點可以填補沒有虛字段或抽象字段的缺憾在設計組件的時候非常有用也體現了C#這樣的componentoriented語言的精神內涵
但如果沒有上述理由而且日後對程序做大的改動可能性比較小時我想也大可不必非要把每個public字段都要變成屬性比如在設計一些輕型的struct用於互操作的時候直接使用public字段沒什麼不好所以感覺本條目Bill Wagner先生使用Always Use Properties Instead of Accessible Data Members顯得太過強硬
其實這裡的討論也表明閱讀《Effective C#》一書時需要注意的地方即Effective原則並不是放之四海而皆准的不同的項目（組件化復用程度較高的項目？還是一次編寫N年都run的項目）不同的角色（類庫/組件開發人員？還是應用程序開發人員？）有著不同的Effective准則事實上書中很多Items都是從類庫/組件開發人員的角度來考慮的
關於屬性的性能問題需要談一點如果僅僅是簡單地以存取模式來使用屬性在相當程度上是沒有性能損失的因為在JIT編譯過程中已經做了inline的處理不過inline處理還是有一些基本的條件有些情況下JIT編譯器不會inline比如虛調用方法的IL代碼長度過長（目前CLR的規定是超過bytes為代碼長度過長）有復雜的控制流邏輯有異常處理等這些條件都是要麼根本不能使用inline（比如虛屬性）要麼inline的代價太大容易導致代碼的bloat要麼是inline起來很費時間——已經喪失了inline的意義因為NET的inline機制發生在JIT過程中使用屬性有個別讓人感覺不舒服的地方比如它影響開發人員的開發效率但對代碼運行的效率不產生影響
明辨值類型和引用類型的使用場合
這個條款討論的是類型設計時候的tradeoff——是將類型設計為結構還是類Bill Wagner先生給出了一個原則值類型用於存儲數據引用類型用於定義行為（value types store values and reference types define behavior）
如何判斷這個原則的適用性Bill Wagner也給出了一個方法那就是首先回答下面幾個問題
該類型的主要職責是否用於數據存儲？
該類型的公有接口是否都是一些存取屬性？
是否確信該類型永遠不可能有子類？
是否確信該類型永遠不可能具有多態行為？
如果所有問題的答案都是yes那麼就應該采用值類型這樣的判斷確實有很好的理由支撐但是我個人認為將這個問題回答為yes還不足以構成采用值類型的全部理由因為在很多項目實踐中我發現值類型帶來的性能問題不可小視值類型帶來的性能問題主要有兩個
由於值類型實例在棧和托管堆之間的轉換而導致的box/unbox以及由此帶來的托管堆上的垃圾
值類型默認情況下采用的是值拷貝語義如果是比較大的值類型在傳遞參數和函數返回值時同樣會帶來性能問題
關於第條Bill Wagner在本條款中提到了引用類型會給垃圾收集器帶來負擔這個表面看似正確的判斷但是由於box/unbox的效應有些情況下反倒是值類型給垃圾收集器帶來了更多的負擔比如將一些值類型放到一個集合中然後又頻繁地對其進行讀寫操作如果碰到這種情況我想放棄結構而采用類未嘗不是一種更好的做法事實上將一個用作數據存儲的值類型（比如SystemDrawingPoint）添加到一個集合（SystemCollectionsArrayList）中是一個太常見不過的操作不過C# 中新引入的泛型技術對box/unbox的問題有極大的改善
關於第條Scott Meyers先生在Effective C++的第條盡量使用passbyreference（傳址）少用passbyvalue（傳值）中講的比較清楚雖然由於C#中的結構類型具有默認的深拷貝語義沒有拷貝構造器的調用而且結構類型也沒有子類因此在某種程度上來講不具有多態性也就沒有C++對象傳值時可能出現的切割（slicing）效應但是值拷貝的成本仍然不小尤其是在這個值類型比較大的情況下問題就比較嚴重實際上在NET框架的Design Guidelines for Class Library Developers文檔中在說明什麼時候應該使用結構類型的時候其中提到了一項原則（還有其他一些並行原則）——類型實例數據的大小要小於個字節該文檔主要是從類型的運行效率層面來考慮的而Bill Wagner先生這裡的條款主要是從類型的設計層面來考慮的
從上述兩條討論來看我個人傾向於對結構類型采取更為保守的設計策略而對於類則可以積極大膽地使用因為將結構類型不適當地設計為類帶來的不良後果要遠遠小於將類不適當地設計為結構類型所帶來的不良後果就目前的經驗來看我甚至認為只有和非托管互操作打交道的情況才是使用結構類型最充足的理由其他情況都要三思而後行當然在C# 中引入泛型技術之後box/unbox將不再是一個沉重的負擔應付一些非常輕量級的場合結構類型依然有自己的一席之地
From:http://tw.wingwit.com/Article/program/net/201311/12377.html
