《Effective C#》条款1：使用属性代替可访问的数据成员

结论：只要打算将数据暴露在类型的公有接口或者受保护接口中，我们都应该使用属性来实现。对于具有序列或者字典特征的类型，则应该采用索引器。所有的数据成员都应一律声明为私有。（如果你熟悉属性语法、记住这个结论就可以了）一、属性（property）和数据成员的基本语法：

public class Customer
...{
   private string _name;
   public string Name2;
   public string Name
   ...{
     get
     ...{
       return _name;
     }
    set
    ...{
      if (( value == null ) || ( value.Length == 0 ))
        throw new ArgumentException( "Name cannot be blank", "Name" );
      _name = value;
    }
  }
  // ……
}

//程序调用
Customer customerOne = new Customer();
customerOne.Name = "This Company, Inc."; //属性设置
customerOne.Name2 = "This Company, Inc."; //数据成员设置
string name = customerOne.Name;//属性获取
string name2 = customerOne.Name2;//数据成员获取

从上面的语法可以看到属性和数据成员在使用上是一样的，但是在定义上还是有很大的区别的；

二、属性的优点：

1、可以得到更好的数据绑定支持；数据成员则不可以
2、可以更容易地在将来对其访问方法的实现做任何改变；
3、可以更容易的在属性上进行业务逻辑的限制；

四、

属性和数据成员的性能比较

：

几乎没有区别

reference : http://blog.csdn.net/hy_lihuan/archive/2007/12/25/1967228.aspx

學習研究.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試圖要歸納的使用屬性的理由：
　　1.可以對賦值做校驗、或者額外的處理
　　2.可以做執行緒同步
　　3.可以使用虛屬性、或者抽象屬性
　　4.可以將屬性置於interface中
　　5.可以提供get-only或者set-only版本，甚至可以給讀、寫以不同的存取權限（C# 2.0支持）
　　個人感覺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的規定是超過32bytes為代碼長度過長），有複雜的控制流邏輯，有異常處理等。這些條件都是要麼根本不能使用inline（比如虛屬性），要麼inline的代價太大，容易導致代碼的bloat，要麼是inline起來很費時間——已經喪失了inline的意義，因為.NET的inline機制發生在JIT過程中。使用屬性有個別讓人感覺不舒服的地方，比如它影響開發人員的開發效率，但對代碼運行的效率不產生影響。
　　明辨數值型別和參考類型的使用場合
　　這個條款討論的是類型設計時候的tradeoff——是將類型設計為結構還是類。Bill Wagner先生給出了一個原則“數值型別用於存儲資料，參考類型用於定義行為（value types store values and reference types define behavior）”。
　　如何判斷這個原則的適用性，Bill Wagner也給出了一個方法，那就是首先回答下面幾個問題：
　　1.該類型的主要職責是否用於資料存儲？
　　2.該類型的公有介面是否都是一些存取屬性？
　　3.是否確信該類型永遠不可能有子類？
　　4.是否確信該類型永遠不可能具有多態行為？
　　如果所有問題的答案都是yes，那麼就應該採用數值型別。這樣的判斷確實有很好的理由支撐，但是我個人認為“將這4個問題回答為yes”還不足以構成採用數值型別的全部理由。因為在很多專案實踐中，我發現數值型別帶來的性能問題不可小視。數值型別帶來的性能問題主要有兩個：
　　1.由於數值型別實例在棧和託管堆之間的轉換而導致的box/unbox，以及由此帶來的託管堆上的垃圾。
　　2.數值型別預設情況下採用的是值拷貝語義，如果是比較大的數值型別，在傳遞參數和函數返回值時，同樣會帶來性能問題。
　　
　　關於第1條，Bill Wagner在本條款中提到了“參考類型會給垃圾收集器帶來負擔”這個表面看似正確的判斷。但是由於box/unbox的效應，有些情況下，反倒是數值型別給垃圾收集器帶來了更多的負擔。比如將一些數值型別放到一個集合中，然後又頻繁地對其進行讀寫操作。如果碰到這種情況，我想“放棄結構而採用類”未嘗不是一種更好的做法。事實上，將一個用作資料存儲的數值型別（比如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++物件傳值時可能出現的切割（slicing）效應。但是值拷貝的成本仍然不小。尤其是在這個數值型別比較大的情況下，問題就比較嚴重。實際上，在.NET框架的Design Guidelines for Class Library Developers文檔中，在說明什麼時候應該使用結構類型的時候，其中提到了一項原則（還有其他一些並行原則）——類型實例資料的大小要小於16個位元組。該文檔主要是從類型的運行效率層面來考慮的，而Bill Wagner先生這裡的條款主要是從類型的設計層面來考慮的。
　　從上述兩條討論來看，我個人傾向於對結構類型採取更為保守的設計策略。而對於類則可以積極大膽地使用。因為“將結構類型不適當地設計為類”帶來的不良後果要遠遠小於“將類不適當地設計為結構類型”所帶來的不良後果。就目前的經驗來看，我甚至認為只有和非託管交互操作打交道的情況才是使用結構類型最充足的理由，其他情況都要“三思而後行”。當然，在C# 2.0中引入泛型技術之後，box/unbox將不再是一個沉重的負擔，應付一些非常羽量級的場合，結構類型依然有自己的一席之地。
http://www.uml.org.cn/net/200608211.htm

ref :http://www.cnblogs.com/pandengfeng/articles/618510.html

回首頁