1、为什么程序已经可以正常工作了，我们还要改变它们呢？答案就是我们可以让它们变得更好。我们常常会改变所使用的工具或者语言，因为新的工具或者语言更富生产力。如果固守旧有的习惯，我们将得不到期望的结果。对于 C#这种和我们已经熟悉的语言（如 C+或 Java）有诸多共通之处的新语言，情况更是如此。人们很容易回到旧的习惯中去。当然，这些旧的习惯绝大多数都很好，C#语言的设计者们也确实希望我们能够利用这些旧习惯下所获取的知识。但是，为了让 C#和公共语言运行库（Common Language Runtime，CLR ）能够更好地集成在一起，从而为面向组件的软件开发提供更好的支持，这些设计者们不可避免地需要
2、添加或者改变某些元素。本章将讨论那些在 C#中应该改变的旧习惯，以及对应的新的推荐做法。条款 1：使用属性代替可访问的数据成员C#将属性从其他语言中的一种特殊约定提升成为一种第一等（first-class）的语言特性。如果大家还在类型中定义公有的数据成员，或者还在手工添加 get 和 set 方法，请赶快停下来。属性在使我们可以将数据成员暴露为公有接口的同时，还为我们提供了在面向对象环境中所期望的封装。在 C#中，属性（property）是这样一种语言元素：它们在被访问的时候看起来好像是数据成员，但是它们却是用方法实现的。有时候，一些类型成员最好的表示形式就是数据，例如一个客户的名字、一个点的
3、 x/y 坐标，或者上一年的收入。使用属性我们可以创建一种特殊的接口 这种接口在行为上像数据访问，但却仍能获得函数的全部好处。客户代码1对属性的访问就像访问公有变量一样。但实际的实现采用的却是方法，这些方法内部定义了属性访问器的行为。.NET 框架假定我们会使用属性来表达公有数据成员。事实上，.NET 框架中的数据绑定类只支持属性，而不支持公有数据成员。这些数据绑定类会将对象的属性关联到用户界面控件（Web 控件或者 Windows Forms 控件）上。其数据绑定机制事实上是使用反射来查找一个类型中具有特定名称的属性。例如下面的代码：textBoxCity.DataBindings.Add(
4、“Text“,address, “City“);便是将 textBoxCity 控件的 Text 属性和 address 对象的 City 属性绑定在一起。（有关数据绑定的细节，参见条款38。）如果 City 是一个公有数据成员，这样的数据绑定就不能正常工作。.NET 框架类库（Framework Class Library）的设计者们之所以不支持这样的做法，是因为将数据成员直接暴露给外界不符合面向对象的设计原则。.NET 框架类库这样的设计策略从某种意义上讲也是在推动我们遵循面向对象的设计原则。对于 C+和 Java 编程老手，我想特别指出的是这些数据绑定代码并不会去查找 get 和 set
5、 函数。在 C#中，我们应该忘掉 get_和 set_这些旧式的约定，而全面采用属性。当然，数据绑定所应用的类一般都要和用户界面打交道。但这并不意味着属性只在 UI（用户界面）逻辑中有用武之地。对于其他类和结构，我们也需要使用属性。随着时间的推移，新的需求或行为往往会影响原来类型的实现，采用属性比较容易能够应对这些变化。例如，我们可能很快就会发现 Customer 类型不能有一个空的 Name。如果我们使用一个公用属性来实现 Name，那么只需要在一个地方做更改即可：public class Customerprivate string _name;public string Namegetr
6、eturn _name;setif ( value = null ) |( value.Length = 0 )throw new ArgumentException( “Name cannot be blank“,“Name“ );_name = value;/ 如果使用的是公有数据成员，我们就要寻找并修改所有设置 Customer 的 Name 的代码，那将花费大量的时间。另外，由于属性是采用方法来实现的，因此为它们添加多线程支持就更加容易直接在 get 和 set 方法中提供同步数据访问控制即可：public string Namegetlock( this )return _name;
7、setlock( this )_name = value;既然是采用方法来实现的，那么属性也就具有了方法所具有的全部功能。比如，属性可以实现为虚属性：public class Customerprivate string _name;public virtual string Namegetreturn _name;set_name = value;/ 忽略其他实现代码。自然，属性也可以实现为抽象属性，或者作为接口定义的一部分：public interface INameValuePairobject Nameget;object Valueget;set;最后，我们还可以借助属性的特点来创建
8、 const 和非 const 版本的接口：public interface IConstNameValuePairobject Nameget;object Valueget;public interface INameValuePairobject Valueget;set;/ 上述接口的应用：public class Stuff : IConstNameValuePair, INameValuePairprivate string _name;private object _value;#region IConstNameValuePair Memberspublic object Na
9、megetreturn _name;object IConstNameValuePair.Valuegetreturn _value;#endregion#region INameValuePair Memberspublic object Valuegetreturn _value;set_value = value;#endregion属性在 C#中已经成为一项比较完善的、第一等的语言元素。我们可以针对成员函数做的任何事情，对于属性也同样适用。毕竟，属性是对访问修改内部数据的方法的一种扩展。我们知道，属性访问器在编译后事实上是两个分离的方法。在 C# 2.0 中，我们可以为一个属性的 ge
10、t 访问器和 set访问器指定不同的访问修饰符。这使得我们可以更好地控制属性的可见性。/ 合法的 C# 2.0 代码:public class Customerprivate string _name;public virtual string Namegetreturn _name;protected set_name = value;/ 忽略其他实现代码。C#的属性语法扩展自简单的数据字段。如果类型接口需要包含一些索引数据项，则可以使用一种称作索引器（indexer）的类型成员。索引器在 C#中又称含参属性（parameterized property）。这种“ 使用属性来返回一个序列中的
11、数据项”的做法对于很多场合非常有用，下面的代码展示了这一用法：public int this int index getreturn _theValues index ;set_theValues index = value;/ 访问索引器：int val = MyObject i ;索引器和一般的属性（即支持单个数据项的属性）在 C#中有同样的语言支持，它们都用方法实现，我们可以在其内部做任何校验或者计算工作。索引器也可以为虚索引器，或者抽象索引器。它们可以声明在接口中，也可以成为只读索引器或者读写索引器。以数值作为参数的“一维索引器”还可以参与数据绑定。使用非数值的索引器则可以用来定义 m
12、ap 或者 dictionary 等数据结构：public Address this string name getreturn _theValues name ;set_theValues name = value;与 C#中的多维数组类似，我们也可以创建“多维索引器”其每一维上的参数类型可以相同，也可以不同。public int this int x, int y getreturn ComputeValue( x, y );public int this int x, string name getreturn ComputeValue( x, name );注意所有的索引器都使用 th
13、is 关键字来声明。我们不能为索引器指定其他的名称。因此，在每个类型中，对于同样的参数列表，我们只能有一个索引器。属性显然是一个好东西，相较于以前的各种访问方式来讲，它的确是一个进步。但是，有些读者可能会有如下的想法：刚开始先使用数据成员，之后如果需要获得属性的好处时，再考虑将数据成员替换为属性。这种做法听起来似乎有道理，但实际上是错的。让我们来看下面一段代码：/ 使用公有数据成员，不推荐这种做法：public class Customerpublic string Name;/ 忽略其他实现代码。这段代码描述了一个 Customer 类，其内包含一个成员 Name。我们可以使用成员访问符来获
14、取设置其 Name 的值：string name = customerOne.Name;customerOne.Name = “This Company, Inc.“;这段代码非常简洁和直观。有人据此就认为以后如果有需要，再将 Customer 类的数据成员 Name 替换为属性就可以了，而使用 Customer 类型的代码无需做任何改变。这种说法从某种程度上来讲是对的。属性在被访问的时候和数据成员看起来没有什么差别。这正是 C#引入新的属性语法的一个目标。但属性毕竟不是数据，访问属性和访问数据产生的是不同的 MSIL。前面那个 Customer 类型的 Name 字段在编译后将产生如下MSI
15、L 代码：.field public string Name而访问该字段的部分编译后的 MSIL 代码如下：ldloc.0ldfld string NameSpace.Customer:Namestloc.1向该字段存储数据的部分编译后的 MSIL 代码如下：ldloc.0ldstr “This Company, Inc.“stfld string NameSpace.Customer:Name大家不必担忧，我们不会整天围绕着 IL 代码转。为了让大家清楚“在数据成员和属性之间做改变会打破二进制兼容性”，在这里展示一下 IL 代码还是很重要的。我们再来看下面的 Customer 类型实现，这次
16、我们采用了属性的方案：public class Customerprivate string _name;public string Namegetreturn _name;set_name = value;/ 忽略其他实现代码。当我们在 C#中访问 Name 属性时，使用的语法和前面访问字段的语法一模一样。string name = customerOne.Name;customerOne.Name = “This Company, Inc.“;但是，C#编译器对于两段相同的 C#代码产生的却是完全不同的 MSIL 代码。我们来看新版 Customer 类型的 Name属性编译后的 MSIL
17、:.property instance string Name().get instance string NameSpace.Customer:get_Name().set instance void NameSpace.Customer:set_Name(string) / 属性 Customer:Name 结束。.method public hidebysig specialname instance stringget_Name() cil managed/ 代码长度 11 (0xb).maxstack 1.locals init (0 string CS$00000003$00000
18、000)IL_0000: ldarg.0IL_0001: ldfld string NameSpace.Customer:_nameIL_0006: stloc.0IL_0007: br.s IL_0009IL_0009: ldloc.0IL_000a: ret / 方法 Customer:get_Name 结束。.method public hidebysig specialname instance voidset_Name(string value) cil managed/ 代码长度 8 (0x8).maxstack 2IL_0000: ldarg.0IL_0001: ldarg.1I
19、L_0002: stfld string NameSpace.Customer:_nameIL_0007: ret / 方法 Customer:set_Name 结束。在将属性定义从 C#代码转换为 MSIL 的过程中，有两点需要我们注意：首先，.property 指示符定义了属性的类型，以及实现属性 get 访问器和 set 访问器的两个函数。这两个函数被标记为 hidebysig 和 specialname。对我们来说，这两个标记意味着它们所修饰的函数不能直接在 C#源代码中被调用，也不被认为是类型正式定义的一部分。要访问它们，我们只能通过属性。当然，大家对于属性定义产生不同的 MSIL
20、应该早有预期。更重要的是，对属性所做的 get 和 set 访问的客户代码编译出来的 MSIL 也不同：/ getldloc.0callvirt instance string NameSpace.Customer:get_Name()stloc.1/ setldloc.0ldstr “This Company, Inc.“callvirt instance void NameSpace.Customer:set_Name(string)大家看到了，同样是访问客户（Customer）名称（Name）的 C#源代码，由于所使用的 Name 成员不同属性或者数据成员，编译后产生出的 MSIL 指令
21、也不同。尽管访问属性和访问数据成员使用的是同样的 C#源代码，但是C#编译器却将它们转换为不同的 IL 代码。换句话说，虽然属性和数据成员在源代码层次上是兼容的，但是在二进制层次上却不兼容。这意味着如果将一个类型的公有数据成员改为公有属性，那么我们必须重新编译所有使用该公有数据成员的 C#代码。本书第章“ 创建二进制组件”讨论了二进制组件的相关细节，但是在此之前大家要清楚，将一个数据成员改为属性会破坏二进制兼容性。如果这样的程序集已经被部署，那么升级它们的工作将变得非常麻烦。看了属性产生的 IL 代码之后，有读者可能想知道使用属性和使用数据成员在性能上有什么差别。虽然使用属性不会比使用数据成员
22、的代码效率更快，但是它也不见得就会比使用数据成员的代码慢，因为 JIT 编译器会对某些方法调用（包括属性访问器）进行内联处理。如果 JIT 编译器对属性访问器进行了内联处理，那么属性和数据成员的效率将没有任何差别。即使属性访问器没有被内联，实际的效率差别相对于函数调用的成本来讲也是可以忽略不计的。只有在很少的一些情况下，这种差别才值得我们注意。综上所述，只要打算将数据暴露在类型的公有接口或者受保护接口中，我们都应该使用属性来实现。对于具有序列或者字典特征的类型，则应该采用索引器。所有的数据成员都应一律声明为私有。使用属性的好处显而易见：我们可以得到更好的数据绑定支持，我们可以更容易地在将来对其
23、访问方法的实现做任何改变。将变量封装在属性中只不过增加一两分钟代码录入时间。如果刚开始使用数据成员，后来又发现需要使用属性，这时再来修改的成本将是几个小时。今天的一点投入，会为明天节省许多时间。条款 2：运行时常量（readonly）优于编译时常量（const）C#语言有两种不同的常量机制：一种为编译时 （compile-time）常量，一种为运行时（runtime）常量。两种常量有着非常迥异的行为，使用不正确会导致程序的性能下降或者出现错误。这 两种代价，哪一个都没有人愿意承担，但是如果必须承担一个，那么“慢、但是能够正确运行的”程序总比“快、但是可能出错的”程序要好。因此，我们说运行时 常
24、量优于编译时常量。编译时常量比运行时常量稍微快一点，但却缺乏灵活性。只有在性能非常关键，并且其值永远不会改变的情况下，我们才应该使用编译时常 量。在 C#中，我们使用 readonly 关键字来声明运行时常量，用 const 关键字来声明编译时常量。/ 编译时常量：public const int _Millennium = 2000;/ 运行时常量：public static readonly int _ThisYear = 2004;编译时常量与运行时常量行为的不同处在于它们的访问方式。编译时常量在编译后的结果代码中会被替换为该常量的值，例如下面的代码：if ( myDateTime.Ye
25、ar = _Millennium )其编译后的 IL 和下面的代码编译后的 IL 一样：if ( myDateTime.Year = 2000 )条款 2：运行时常量（readonly）优于编译时常量（const） 16运行时常量的值则在运行时被计算。对于使用运行时常量的代码，其编译后的 IL 将维持对 readonly 变量（而非它的值）的引用。 这种差别会为我们使用两种常量类型带来一些限制。编译时常量只可以用于基元类型（包括内建的整数类型和浮点类型）、枚举类型或字符串类型。因为只有这些类型才允许我们在初始化器中指定有意义的常量值2。在使用这些常量的代码编译后得到的 IL 代码中，常量将直接
26、被替换为它们的字面值（literal）。例如，下面的代码就不会通过编译。事实上，C#不允许我们使用 new 操作符来初始化一个编译时常量，即使被初始化的常量类型为一个值类型。/ 下面的代码不会通过编译，但是换成 readonly 就可以：private const DateTime _classCreation = newDateTime( 2000, 1, 1, 0, 0, 0 );编译时常量仅限于数值和字符串。只读（read- only）字段之所以也被称作一种常量，是因为它们的构造器一旦被执行，我们将不能对它们的值做任何修改。与编译时常量不同的地方在于，只读字段的赋值操 作发生在运行时，因
27、此它们具有更多的灵活性。比如，只读字段的类型就没有任何限制。对于只读字段，我们只能在构造器或者初始化器中为它们赋值。在上面的代 码中，我们可以声明 readonly 的 DateTime 结构变量，但是却不能声明 const的 DateTime 结构变量。我们可以声明 readonly 的实例常量，从而为一个类型的每个实例存储不同的值。但是 const 修饰的编译时常量默认就被定义为静态常量。我们知道，运行时常量和编译时常量最重要的区别就 在于运行时常量值的辨析发生在运行时，而编译时常量值的辨析发生编译时。换言之，使用运行时常量编译后的 IL 代码引用的是 readonly 变量，而非它的 值
28、；而使用编译时常量编译后的 IL 代码将直接引用它的值就像我们直接在代码中使用常量值一样。即使我们使用的是数值常量并跨程序集引用，情况也是一 样：如果在程序集 A 中引用程序集 B 中的常量，那么编译后程序集 A 中出现的那个常量将被它的值所替换。这种差别对于代码的维护性而言有着相当的影响。编译时常量与运行时常量被辨析的方式影响着运行时的兼容性。假设我们在一个名为 Infrastructure 的程序集中分别定义了一个 const 字段和一个 readonly 字段：public class UsefulValuespublic static readonly int StartValue =
29、 5;public const int EndValue = 10;在另外一个程序集 Application 中，我们又引用着这些值：for ( int i = UsefulValues.StartValue;i UsefulValues.EndValue;i+ )Console.WriteLine( “value is 0“, i );如果我们运行上面的代码，将得到以下输出：Value is 5Value is 6.Value is 9假设随着时间的推移，我们又发布了一个新版的 Infrastructure 程序集：public class UsefulValuespublic static
30、 readonly int StartValue = 105;public const int EndValue = 120;我们将新版的 Infrastructure 程序集分发出去，但并没有重新编译 Application 程序集。我们期望得到如下的输出：Value is 105Value is 106.Value is 119但实际上，我们却没有得到任何输出。因为现在那个循环语句将使用 105 作为它的起始值，使用 10 作为它的结束 条件。其根本原因在于 C#编译器在第一次编译 Application 程序集时，将其中的 EndValue 替换成了它对应的常量值 10。而对于 Star
31、tValue 来说，由于它被声明为 readonly，所以它的辨析发生在运行时。因此，Application程序集在没有被重新编译的情况下， 仍然可以使用新的 StartValue 值。为了改变所有使用 readonly 常量的客户代码的行为，简单地安装一个新版的 Infrastructure 程序集就足够了。“更改一个运行时常量的值”应该被视作对类型接口的更改，其后果是我们必须重新编译所有引用该常量的代码。“更改一个公有的运行时常量的 值”应该被视作对类型实现的更改，它与其客户代码在二进制层次上是兼容的。大家看看上述代码中的循环编译后的MSIL，就会对这里所谈的更加清楚了：IL_0000:
32、ldsfld int32 Chapter1.UsefulValues:StartValueIL_0005: stloc.0IL_0006: br.s IL_001cIL_0008: ldstr “value is 0“IL_000d: ldloc.0IL_000e: box mscorlibSystem.Int32IL_0013: call void mscorlibSystem.Console:WriteLine(string,object)IL_0018: ldloc.0IL_0019: ldc.i4.1IL_001a: addIL_001b: stloc.0IL_001c: ldloc.
33、0IL_001d: ldc.i4.s 10IL_001f: blt.s IL_0008大家可以在这段 MSIL 代码的顶端看到 StartValue 的确是被动态加载的，而在其末尾可以看到结束条件被硬编码（hard-code）为 10。不过，有时候有些值确实可以在编译时确定，这时候 就应该使用编译时常量。例如，考虑在对象的序列化形式（有关对象序列化，可参见条款 25）中使用一组常量来区分不同版本的对象。其中，标记特殊版本号的持 久化数据应该采用编译时常量，因为它们的值永远不会改变。但是标记当前版本号的数据应该采用运行时常量，因为它的值会随着每个不同的版本而改动。private const in
34、t VERSION_1_0 = 0x0100;private const int VERSION_1_1 = 0x0101;private const int VERSION_1_2 = 0x0102;/ 主发行版本：private const int VERSION_2_0 = 0x0200;/ 标记当前版本：private static readonly int CURRENT_VERSION =VERSION_2_0;我们使用运行时版本3来将当前的版本号存储在每一个序列化文件中：/ 从持久层数据源读取对象，将存储的版本号与编译时常量相比对：protected MyType( Serial
35、izationInfo info,StreamingContext cntxt )int storedVersion = info.GetInt32( “VERSION“ );switch ( storedVersion )case VERSION_2_0:readVersion2( info, cntxt );break;case VERSION_1_1:readVersion1Dot1( info, cntxt );break;/ 忽略其他细节。/ 写入当前版本号： SecurityPermissionAttribute( SecurityAction.Demand,Serializati
36、onFormatter =true ) void ISerializable.GetObjectData( SerializationInfo inf,StreamingContext cxt )/ 使用运行时常量来标记当前版本号：inf.AddValue( “VERSION“, CURRENT_VERSION );/ 写入其他元素条款 3：操作符 is 或 as 优于强制转型 19使用 const 较之于使用 readonly 的唯一好处就是性能：使用已知常量值的代码效率要比访问 readonly 值的代码效率稍好一点。但是这其中的效 率提升是非常小的，大家应该和其所失去的灵活性进行一番权衡
37、比较。在打算放弃灵活性之前，一定要对两者的性能差别做一个评测。 综上所述，只有当某些情况要求变量的值必须在编译时可用，才应该考虑使用 const，例如：特性（attribute）类的参数，枚举定义，以及某些不随组件版本变化而改变的值。否则，对于其他任何情况，都应该优先选择readonly 常量，从而获得其所具有的灵活性。条款 3：操作符 is 或 as 优于强制转型C#是一门强类型语言。一般情况下，我们最好避免 将一个类型强制转换为其他类型。但是，有时候运行时类型检查是无法避免的。相信大家都写过很多以 System.Object 类型为参数的函数，因为. NET 框架预先为我们定义了这些函数的
38、签名。在这些函数内部，我们经常要把那些参数向下转型为其他类型，或者是类，或者是接口。对于这种转型，我们通常有 两种选择：使用 as 操作符，或者使用传统 C 风格的强制转型。另外还有一种比较保险的做法：先使用 is 来做一个转换测试，然后再使用 as 操作符或者强制转 型。正确的选择应该是尽可能地使用 as 操作符，因为它比强制转型要安全，而且在运行时层面也有比较好的效率。需要注意的是，as 和 is 操作符都不执行任何用户自定义的转换。只有当运行时类型与目标转换类型匹配时，它们才会转换成功。它们永远不会在转换过程中构造新的对象。我们来看一个例子。假如需要将一个任意的对象转换为一个 MyType 的实例。我们可能会像下面这样来做：object o = Factory.GetObject( );/ 第一个版本：MyType t = o as MyType;
