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

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

一、属性（property）和数据成员的基本语法：

 1public class Customer
 2{
 3  private string _name;
 4  public string Name2;
 5  public string Name
 6  {
 7    get
 8    {
 9      return _name;
10    }
11    set
12    {
13      if (( value == null ) ||
14        ( value.Length == 0 ))
15        throw new ArgumentException( "Name cannot be blank",
16          "Name" );
17      _name = value;
18    }
19  }
20  // ……
21}
22
23//程序调用
24Customer customerOne = new Customer();
25customerOne.Name = "This Company, Inc."; //属性设置
26customerOne.Name2 = "This Company, Inc."; //数据成员设置
27string name = customerOne.Name;//属性获取
28string name2 = customerOne.Name2;//数据成员获取
29

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

二、属性的优点：

1、可以得到更好的数据绑定支持；数据成员则不可以

2、可以更容易地在将来对其访问方法的实现做任何改变；

3、可以更容易的在属性上进行业务逻辑的限制；

三、属性的特点：

1、我们可以针对成员函数做的任何事情，对于属性也同样适用。

因此属性可以实现为虚属性；也可以实现为抽象属性，或者作为接口定义的一部分；

2、在C# 2.0中，我们可以为一个属性的get访问器和set访问器指定不同的访问修饰符。（可以更好地控制属性的可见性）

3、索引器：索引器和一般的属性（即支持单个数据项的属性）在C#中有同样的语言支持，它们都用方法实现，我们可以在其内部做任何校验或者计算工作。索引器也可以为虚索引器，或者抽象索引器。它们可以声明在接口中，也可以成为只读索引器或者读—写索引器。以数值作为参数的“一维索引器”还可以参与数据绑定。使用非数值的索引器则可以用来定义map或者dictionary等数据结构； 

注意：在每个类型中，对于同样的参数列表，我们只能有一个索引器。

 1//索引器定义
 2public int this [ int index ]
 3{
 4  get
 5  {
 6    return _theValues [ index ] ;
 7  }
 8  set
 9  {
10    _theValues[ index ] = value;
11  }
12}
13// 访问索引器：
14int val = MyObject[ i ];
15
16//多维索引器定义
17public int this [ int x, int y ]
18{
19  get
20  {
21    return ComputeValue( x, y );
22  }
23}
24public int this[ int x, string name ]
25{
26  get
27  {
28    return ComputeValue( x, name );
29  }
30}
31

四、属性和数据成员的性能比较：几乎没有区别

    使用属性和使用数据成员在性能上有什么差别。虽然使用属性不会比使用数据成员的代码效率更快，但是它也不见得就会比使用数据成员的代码慢，因为JIT编译器会对某些方法调用（包括属性访问器）进行内联处理。如果JIT编译器对属性访问器进行了内联处理，那么属性和数据成员的效率将没有任何差别。即使属性访问器没有被内联，实际的效率差别相对于函数调用的成本来讲也是可以忽略不计的。

五、讨论和理解

个人认为属性最大的好处就是符合面向对象和语言设计的要求，做到了多处使用（调用），一次修改的原则；毕竟在项目开展的过程中，修改是不可避免的，既然不能避免，那自然就需要考虑编程方式方便修改；属性在这方面做得不错，可以通过对属性的一些限制来保证UI调用的准确性并不需要在页面中去寻找需要限制的内容；事例可以看最上面的代码，这个Name属性就要求不能为null的，如果未null就会报错；这样就不需要在每一次调用这个属性的时候进行不能为空的监测工作，减少了代码错误的可能性；

至于书上面所说的数据成员修改属性这个问题，我觉得只要养成习惯，就不要再去使用数据成员了；就算是数据成员再修改成属性也没有什么大的问题（说上说的原因是编译以后部署会花费更多的时间），对项目的修改一定是在存在问题或者更新需求的情况下，因此重新编译的必要的，所以感觉不比讲究这些。