使用屬性，避免將資料成員直接暴露給外界
學習研究 .NET 的早期，經常碰到一些學習 C#/.Net 的朋友問，要屬性這種華而不實的東西做什麼？後來做專案時也時常接到 team 裡的人的抱怨反饋，為什麼不直接放一個 public 欄位？如：
class Card
{
public string Name;
}
而非要做一個 private 欄位 + public 屬性？
class Card
{
private string name;
public string Name
{
get { return this.name; }
set { this.name = value; }
}
}
我記得在早期的一個專案裡，team 中的一個朋友甚至厭煩了寫 private 欄位 + public 屬性，尤其是碰到一大堆臃腫的 data object class 時候，索性自己寫了一個小工具，來提供一個類別的欄位名和型別，然後自動為該類別生成相應的 private 欄位 + public 屬性。
我在編程的時候是個徹底的實用主義者，用稍微高雅一點的話說叫「不喜歡過度的設計」。如果真的像上面那樣寫 Card，而且在將來沒有什麼改變的需求，我也不喜歡像上面第 2 段程式那樣把事情故意搞得複雜。但如果從 component 的角度來講，總有一些 class 是要供外部長久地使用，也潛在地在將來有被改變的需求。這時候，提供屬性就很有必要了。
這就是這個 Item 試圖要歸納的使用屬性的理由：
個人感覺第 3、4 條是屬性最大的優點，可以填補沒有「虛欄位」或「抽象欄位」的缺憾，在設計組件的時候非常有用，也體現了 C# 這樣的 component-oriented 語言的精神內涵。
但如果沒有上述理由，而且日後對程式做大的改動可能性比較小時，我想也大可不必非要把每個 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 的規定是超過 32 bytes 為程式碼長度過長），有複雜的控制流邏輯，有例外處理等。這些條件都是要麼根本不能使用 inline（比如虛屬性），要麼 inline 的代價太大，容易導致程式碼膨脹，要麼是 inline 起來很費時間——已經喪失了 inline 的意義，因為 .Net 的 inline 機制發生在 JIT 過程中。使用屬性有個別讓人感覺不舒服的地方，比如它影響開發人員的開發效率，但對程式碼執行的效率不產生影響。
