我眼中的C# 3.0之如何创建属性？

缘起

      每次有新技术发布时，我们总能感受到两种截然不同的情绪：一种是恐惧和抵抗，伴随着这种情绪的还有诸如"C# 2.0用的挺好的，为什么要在C# 3.0搞到那么复杂？"或者"我还在使用C# 1.0呢？"等言辞；另一种则是兴奋和拥抱，伴随着这种情绪的还有诸如"原来这个问题在C# 3.0里可以这么简单！"等言辞。

      最近我在公司内部做一个LINQ的系列讲座，在我为其中C# 3.0新特性这一讲准备演示文稿时，突然萌生了写下这篇文章的念头。语言的特性乃至其本身并没有对错之分，是否接受在很大程度上是一个感性问题，即你是否喜欢这样的做事方式，我并没有打算说服任何人接受C# 3.0和LINQ，写这篇文章也只是想和大家分享一下我自己的感受。

      有一次我观看一个关于Expression Blend的培训视频，里面说了一句让我印象非常深刻的话：

I know how it works because I know why it works.

      细细品味这句话，你会感受到它所要传达的信息：理解为何需要这个功能可以帮助你更好地理解如何使用这个功能，而这也正是我要在这篇文章里采用的表达方式。

 

你是如何创建属性的？

      如果你长期使用C#，相信你不会对属性这个东西感到陌生。一般地，属性是对私有字段的一个简单包装，就像这样：

代码 1

      使用属性而不是直接公开私有字段的一个好处就是在属性的获取访问器或设置访问器里加入额外的逻辑并不会为客户端代码带来麻烦，例如你想在设置标题的时候做一些额外的检查。但如果你只是简单地包装一下，像上面的代码那样，就会发现你其实多写了不少可以省略的代码。既然Title属性和m_Title私有字段对应，获取访问器就肯定是返回m_Title的值，而设置访问器也肯定是把值设到m_Title。再者，如果你只通过Title属性来访问这个数据，那么m_Title私有字段就会变得无足轻重，这样的话，为什么不交给编译器代劳呢？这个时候，C# 3.0的自动属性就可以派上用场了：

代码 2

      编译器会为你创建一个私有字段，并让获取访问器和设置访问器指向这个私有字段。当然，如果有需要，例如要在获取访问器或设置访问器里加入额外的逻辑时，你随时可以对获取访问器和设置访问器进行展开。

 

你是如何初始化对象的？

现在，假设我们有这样一个类：

代码 3

      你会怎样初始化它？一种做法是用Book的默认构造函数创建对象实例，然后分别为每个属性赋值：

代码 4

      另一种做法是使用C# 3.0对象初始化器：

代码 5

      乍看一下，C# 3.0的做法似乎没有让人感到任何优越感，现在，请你仔细观察一下，这两份代码分别包含多少个";"？代码4有5个";"，意味着它用了5个语句进行初始化；而代码5只有1个";"，意味着它只用了1个语句进行初始化。从词法的角度来看，如果此刻我只能接受一个表达式，那么代码4的做法就帮不上忙了。一个变通的方法是为Book类提供带参的构造函数，但这种方法也有弊端，用户可能只想在初始化时为部分属性提供数据，而我们又无法确切预知用户会提供哪些属性的组合，于是，我们可能要为用户提供足够多的构造函数重载，嗯，有点无聊，也有点多余。另一个变通的方法是提供接受最多参数的构造函数，如果用户为某个参数传递null，那么就忽略与之对应的属性，这个方法比较接近代码5的做法，不同的是，如果你的属性很多，而用户关心的只是很少一部分，就可能不得不输入很多null了。

      现在，假设你要实例化一组Book对象，并把它们储存在一个集合里，你会怎么做？下面是通常的做法：

代码 6

      如果结合使用C# 3.0的对象初始化器和集合初始化器，你就可以把代码简化为：

代码 7

      集合里的每个元素通过","分割，结合对象初始化器使用，整个集合的结构显得比较明晰。字典的初始化也可以同样简单：

代码 8

      说到这里，我相信你也能感觉到，C#似乎正在表达式化，以前需要很多条语句才能做到的事情，现在却可以用单个表达式描述出来，而这种理念也渗透在整个C# 3.0的氛围里