改善C程序的50种

为什么程序已经可以正常工作了，我们还要改变它们呢？答案就是我们可以让它们变得更好。我们常常会改变所使用的工具或者语言，因为新的工具或者语言更富生产力。如果固守旧有的习惯，我们将得不到期望的结果。对于C#这种和我们已经熟悉的语言（如C++或Java）有诸多共通之处的新语言，情况更是如此。人们很容易回到旧的习惯中去。当然，这些旧的习惯绝大多数都很好，C#语言的设计者们也确实希望我们能够利用这些旧习惯下所获取的知识。但是，为了让C#和公共语言运行库（CommonLanguageRuntime，CLR）能够更好地集成在一起，从而为面向组件的软件开发提供更好的支持，这些设计者们不可避免地需要添加或者改变某些元素。本章将讨论那些在C#中应该改变的旧习惯，以及对应的新的推荐做法。条款1：使用属性代替可访问的数据成员C#将属性从其他语言中的一种特殊约定提升成为一种第一等（first-class）的语言特性。如果大家还在类型中定义公有的数据成员，或者还在手工添加get和set方法，请赶快停下来。属性在使我们可以将数据成员暴露为公有接口的同时，还为我们提供了在面向对象环境中所期望的封装。在C#中，属性（property）是这样一种语言元素：它们在被访问的时候看起来好像是数据成员，但是它们却是用方法实现的。有时候，一些类型成员最好的表示形式就是数据，例如一个客户的名字、一个点的x/y坐标，或者上一年的收入。使用属性我们可以创建一种特殊的接口——这种接口在行为上像数据访问，但却仍能获得函数的全部好处。客户代码[1]对属性的访问就像访问公有变量一样。但实际的实现采用的却是方法，这些方法内部定义了属性访问器的行为。.NET框架假定我们会使用属性来表达公有数据成员。事实上，.NET框架中的数据绑定类只支持属性，而不支持公有数据成员。这些数据绑定类会将对象的属性关联到用户界面控件（Web控件或者WindowsForms控件）上。其数据绑定机制事实上是使用反射来查找一个类型中具有特定名称的属性。例如下面的代码：textBoxCity.DataBindings.Add(Text,address,City);便是将textBoxCity控件的Text属性和address对象的City属性绑定在一起。（有关数据绑定的细节，参见条款38。）如果City是一个公有数据成员，这样的数据绑定就不能正常工作。.NET框架类库（FrameworkClassLibrary）的设计者们之所以不支持这样的做法，是因为将数据成员直接暴露给外界不符合面向对象的设计原则。.NET框架类库这样的设计策略从某种意义上讲也是在推动我们遵循面向对象的设计原则。对于C++和Java编程老手，我想特别指出的是这些数据绑定代码并不会去查找get和set函数。在C#中，我们应该忘掉get_和set_这些旧式的约定，而全面采用属性。当然，数据绑定所应用的类一般都要和用户界面打交道。但这并不意味着属性只在UI（用户界面）逻辑中有用武之地。对于其他类和结构，我们也需要使用属性。随着时间的推移，新的需求或行为往往会影响原来类型的实现，采用属性比较容易能够应对这些变化。例如，我们可能很快就会发现Customer类型不能有一个空的Name。如果我们使用一个公用属性来实现Name，那么只需要在一个地方做更改即可：publicclassCustomer{privatestring_name;publicstringName{get{return_name;}set{if((value==null)||(value.Length==0))thrownewArgumentException(Namecannotbeblank,Name);_name=value;}}//……}如果使用的是公有数据成员，我们就要寻找并修改所有设置Customer的Name的代码，那将花费大量的时间。另外，由于属性是采用方法来实现的，因此为它们添加多线程支持就更加容易——直接在get和set方法中提供同步数据访问控制即可：publicstringName{get{lock(this){return_name;}}set{lock(this){_name=value;}}}既然是采用方法来实现的，那么属性也就具有了方法所具有的全部功能。比如，属性可以实现为虚属性：publicclassCustomer{privatestring_name;publicvirtualstringName{get{return_name;}set{_name=value;}}//忽略其他实现代码。}自然，属性也可以实现为抽象属性，或者作为接口定义的一部分：publicinterfaceINameValuePair{objectName{get;}objectValue{get;set;}}最后，我们还可以借助属性的特点来创建const和非const版本的接口：publicinterfaceIConstNameValuePair{objectName{get;}objectValue{get;}}publicinterfaceINameValuePair{objectValue{get;set;}}//上述接口的应用：publicclassStuff:IConstNameValuePair,INameValuePair{privatestring_name;privateobject_value;#regionIConstNameValuePairMemberspublicobjectName{get{return_name;}}objectIConstNameValuePair.Value{get{return_value;}}#endregion#regionINameValuePairMemberspublicobjectValue{get{return_value;}set{_value=value;}}#endregion}属性在C#中已经成为一项比较完善的、第一等的语言元素。我们可以针对成员函数做的任何事情，对于属性也同样适用。毕竟，属性是对访问／修改内部数据的方法的一种扩展。我们知道，属性访问器在编译后事实上是两个分离的方法。在C#2.0中，我们可以为一个属性的get访问器和set访问器指定不同的访问修饰符。这使得我们可以更好地控制属性的可见性。//合法的C#2.0代码:publicclassCustomer{privatestring_name;publicvirtualstringName{get{return_name;}protectedset{_name=value;}}//忽略其他实现代码。}C#的属性语法扩展自简单的数据字段。如果类型接口需要包含一些索引数据项，则可以使用一种称作索引器（indexer）的类型成员。索引器在C#中又称含参属性（parameterizedproperty）。这种“使用属性来返回一个序列中的数据项”的做法对于很多场合非常有用，下面的代码展示了这一用法：publicintthis[intindex]{get{return_theValues[index];}set{_theValues[index]=value;}}//访问索引器：intval=MyObject[i];索引器和一般的属性（即支持单个数据项的属性）在C#中有同样的语言支持，它们都用方法实现，我们可以在其内部做任何校验或者计算工作。索引器也可以为虚索引器，或者抽象索引器。它们可以声明在接口中，也可以成为只读索引器或者读—写索引器。以数值作为参数的“一维索引器”还可以参与数据绑定。使用非数值的索引器则可以用来定义map或者dictionary等数据结构：publicAddressthis[stringname]{get{return_theValues[name];}set{_theValues[name]=value;}}与C#中的多维数组类似，我们也可以创建“多维索引器”——其每一维上的参数类型可以相同，也可以不同。publicintthis[intx,inty]{get{returnComputeValue(x,y);}}publicintthis[intx,stringname]{get{returnComputeValue(x,name);}}注意所有的索引器都使用this关键字来声明。我们不能为索引器指定其他的名称。因此，在每个类型中，对于同样的参数列表，我们只能有一个索引器。属性显然是一个好东西，相较于以前的各种访问方式来讲，它的确是一个进步。但是，有些读者可能会有如下的想法：刚开始先使用数据成员，之后如果需要获得属性的好处时，再考虑将数据成员替换为属性。这种做法听起来似乎有道理，但实际上是错的。让我们来看下面一段代码：//使用公有数据成员，不推荐这种做法：publicclassCustomer{publicstringName;//忽略其他实现代码。}这段代码描述了一个Customer类，其内包含一个成员Name。我们可以使用成员访问符来获取／设置其Name的值：stringname=customerOne.Name;customerOne.Name=ThisCompany,Inc.;这段代码非常简洁和直观。有人据此就认为以后如果有需要，再将Customer类的数据成员Name替换为属性就可以了，而使用Customer类型的代码无需做任何改变。这种说法从某种程度上来讲是对的。属性在被访问的时候和数据成员看起来没有什么差别。这正是C#引入新的属性语法的一个目标。但属性毕竟不是数据，访问属性和访问数据产生的是不同的MSIL。前面那个Customer类型的Name字段在编译后将产生如下MSIL代码：.fieldpublicstringName而访问该字段的部分编译后的MSIL代码如下：ldloc.0ldfldstringNameSpace.Customer::Namestloc.1向该字段存储数据的部分编译后的MSIL代码如下：ldloc.0ldstrThisCompany,Inc.stfldstringNameSpace.Customer::Name大家不必担忧，我们不会整天围绕着IL代码转。为了让大家清楚“在数据成员和属性之间做改变会打破二进制兼容性”，在这里展示一下IL代码还是很重要的。我们再来看下面的Customer类型实现，这次我们采用了属性的方案：publicclassCustomer{privatestring_name;publicstringName{get{return_name;}set{_name=value;}}//忽略其他实现代码。}当我们在C#中访问Name属性时，使用的语法和前面访问字段的语法一模一样。stringname=customerOne.Name;customerOne.Name=ThisCompany,Inc.;但是，C#编译器对于两段相同的C#代码产生的却是完全不同的MSIL代码。我们来看新版Customer类型的Name属性编译后的MSIL:.propertyinstancestringName(){.getinstancestringNameSpace.Customer::get_Name().setinstancevoidNameSpace.Customer::set_Name(string)}//属性Customer::Name结束。.methodpublichidebysigspecialnameinstancestringget_Name()cilmanaged{//代码长度11(0xb).maxstack1.localsinit([0]stringCS$00000003$00000000)IL_0000:ldarg.0IL_0001:ldfldstringNameSpace.Customer::_nameIL_0006:stloc.0IL_0007:br.sIL_000