条款1 使用属性代替可访问的数据成员
属性是个啥，谁在用？
1. C#的属性在被访问的时候看起来好像是数据成员，但其实是方法。
2. 在.NET框架中，一般使用属性表达公有数据成员。
3. .NET框架中的数据绑定类支持属性。
属性比公有数据成员有啥好？
1. 随着时间的推移，新的需求影响原来类型的实现。比如在员工管理系统中有如下代码：
public class Person { private string name; public string Name { get{return name;} set{this.name = value;} } ....//其它属性 }
Person类声明了一个Name的属性，表示这个人的名字。程序运行了一段时间后，需求发生了变化，要求Name必须不为null或者empty。
我们一般的做法会是1）在界面输入的地方增加验证；2）写一个单独的程序或者sql修改数据库的数据。但问题来了如果这个Person类有好几个录入的界面，比如员工的增加界面、员工修改界面，在修改的时候就要修改两次。大家肯定发现了，如果有很多这样界面，那么就需要修改很多这样的地方。再比如Person类被很多子类继承了，比如Leader、BussinessMan等，那么就需要在每个用到这些类地方进行修改。幸亏我们写的是C#，幸亏你用的是属性。只需要完成以下修改就可以到达我们的目的了。
public class Person { private string name; public string Name { get{return name;} set { if(string.IsNullOrEmpty(value)) { throw new ArgumentException("Name cannot be blank","Name"); } this.name = value; } } ....//其它属性 }
这样是不是很方便？类似的，属性添加多线程支持更方便、可以作为接口定义的一部分、可以声明为虚属性、访问权限控制等。这些都是平常大家都会用的，此处就不再细说。
2. 索引器
如果类型接口需要包含一些索引数据项，那么这个时候可以使用索引器。C#中索引器又叫含参属性（parameterized property）。这个语法大家一般不会声明，但却都在使用。比如说
List<int> intList = new List<int>();
Console.Write(intList[0]);
大家可能经常写这种代码，但只是对这个语法的名字不太熟悉，或者经常写但不知道如何声明这种语法。其实这个就是索引器，声明的语法也很简单。比如一个人可能有多个地址(工作地址、家庭住址、籍贯地址等等)，代码如下：
public class Person { private Dictionary<string,Address> addrDic = new Dictionary<string,string>(); public Address this[string name] { get { return addrDic[name]; } set { this.addrDic[name] = value;//此处也可以改为先判断有没有key，没有key就添加。 } } }
除此之外，C#还支持多维索引器，比如public object this[row,col]，可以表示一个excel表格的某行某列的单元格里面的值，这样封装后的Excel帮助类肯定比xx.GetExcelValue(row,col)这种方法更容易使用。
属性有啥不好？
显而易见，使用属性的代码没有使用数据成员的代码效率快（因为属性本质上是方法）。但是，属性也不见得比说那个数据成员的代码慢。这是为什么呢？JIT编译器会对方法进行内联处理（具体含义自行google），属性作为方法的一种也是会进行内联处理，那么属性和数据成员的效率就没有区别。当然，即便没有被内联，属性调用的效率相对于函数调用的成本也是可以忽略不计的，只有在一些极少数的情况下这种差别才值得我们注意。
可不可以先写公有字段，然后再改为属性？
这个问题，大家只记住不可以就行了。具体原因如下：
1. 对于属性和公有字段使用的源代码看起来一样但IL代码是不一样的；
2. 如果一个类型的公有数据成员改为属性，那么会破坏二进制的兼容性，在程序已经部署的情况下可能会带来升级的麻烦。
总结
1. 对于暴漏在类型的公有接口或者受保护接口中的数据，我们应该使用属性。
2. 对于具有序列或者字典特征的类型，我们应该采用索引器。
3. 对于所有的数据成员，我们应该都应该声明为私有。