第1章 C#语言元素...... 1
条款1：使用属性代替可访问的数据成员.. 1
条款2：运行时常量（readonly）优于编译时常量（const）.. 12
条款3：操作符is或as优于强制转型.. 17
条款4：使用Conditional特性代替#if条件编译.. 25
条款5：总是提供ToString()方法.. 31
条款6：明辨值类型和引用类型的使用场合.. 38
条款7：将值类型尽可能实现为具有常量性和原子性的类型.. 44
条款8：确保0为值类型的有效状态.. 51
条款9：理解几个相等判断之间的关系.. 56
条款10：理解GetHashCode()方法的缺陷.. 63
条款11：优先采用foreach循环语句.. 70


第2章 .NET资源管理...... 77
条款12：变量初始化器优于赋值语句.. 82
条款13：使用静态构造器初始化静态类成员.. 84
条款14：利用构造器链.. 87
条款15：利用using和try/finally语句来清理资源.. 93
条款16：尽量减少内存垃圾.. 100
条款17：尽量减少装箱与拆箱.. 103
条款18：实现标准Dispose模式.. 109


第3章 使用C#表达设计...... 117
条款19：定义并实现接口优于继承类型.. 118

条款20：明辨接口实现和虚方法重写.. 125

条款21：使用委托表达回调.. 129
条款22：使用事件定义外发接口.. 131
条款23：避免返回内部类对象的引用.. 137
条款24：声明式编程优于命令式编程.. 142
条款25：尽可能将类型实现为可序列化的类型.. 148
条款26：使用IComparable和IComparer接口实现排序关系.. 156
条款27：避免ICloneable接口.. 163
条款28：避免强制转换操作符.. 167
条款29：只有当新版基类导致问题时才考虑使用new修饰符.. 172

第4章 创建二进制组件...... 177
条款30：尽可能实现CLS兼容的程序集.. 181
条款31：尽可能实现短小简洁的函数.. 186
条款32：尽可能实现小尺寸、高内聚的程序集.. 190
条款33：限制类型的可见性.. 194
条款34：创建大粒度的Web API. 198


第5章 使用框架...... 205
条款35：重写优于事件处理器.. 205
条款36：合理使用.NET运行时诊断.. 208
条款37：使用标准配置机制.. 213
条款38：定制和支持数据绑定.. 217
条款39：使用.NET验证.. 224
条款40：根据需要选用恰当的集合.. 229
条款41：DataSet优于自定义结构.. 237
条款42：利用特性简化反射.. 246
条款43：避免过度使用反射.. 253
条款44：为应用程序创建特定的异常类.. 258


第6章 杂项讨论...... 265
条款45：优先选择强异常安全保证.. 265
条款46：最小化互操作.. 270
条款47：优先选择安全代码.. 277
条款48：掌握相关工具与资源.. 281
条款49：为C# 2.0做准备.. 284
条款50：了解ECMA标准.. 293


索引...... 295



本书就如何高效使用C#语言和.NET库，为程序员们提供了一些实用的建议。本书由50个关键条款（也可看作是50个小主题）组成，这些主题反映了我（及其他C#顾问）和C#开发人员共事时遇到的最常见问题。
与很多C#开发人员一样，我是在从事10多年C++开发之后开始使用C#的。在本书中，讨论了哪些情况下遵循C++实践可能会在使用C#时引发的问题。有一些使用C#的开发人员有着深厚的Java背景，他们可能会发现有些变化相当明显。因为从Java到C#，一些最佳实践发生了改变，我建议Java开发者要格外注意有关值类型的论述（参见第1章）。此外，.NET垃圾收集器和JVM垃圾收集器的行为方式也不尽相同（参见第2章）。
本书中的条款汇集了我最常提供给开发者的建议。虽然并非所有条款都是通用的，但大多数条款都可以很容易地应用到日常的编程工作中。这些条款涵盖了对属性（条款1）、条件编译（条款4）、常量性类型（条款7）、相等判断（条款9）、ICloneable（条款27）和new修饰符（条款29）的论述。我的经验是，在大多数情况下，减少开发时间和编写出色的代码应该是程序员的主要目标。某些科学和工程应用程序最重视的可能是系统的整体性能。对其他应用程序而言，凡事都应该围绕可伸缩性展开。对于不同的目标，可能会找到某些情况下比较重要（或不太重要）的信息。针对这一问题，我设法对各种目标进行了详细的解释说明。书中关于readonly和const（条款2）、可序列化的类型（条款25）、CLS兼容（条款30）、Web方法（条款34）和DataSet（条款41）的讨论针对某些特定的设计目标。这些目标在相应的条款中有清楚的说明，这样读者就可以在特定的情况下决定最适用的做法。
虽然本书中的每个条款都是独立的，但是这些条款是围绕一些重要的主题（如C#语法、资源管理和对象及组件设计）组织起来的，理解这一点非常重要。这并非无心之举。我的目的就是通过将每个条款构建在之前的条款之上，并合理地利用之前的条款，来让读者最大限度地学习书中的内容。尽管如此，大家仍然不要忘了举一反三。对于特定的问题，本书也可以作为一个理想的查询工具。
要记住的是，本书并不是C#语言的教程或指南，也不是为了教授大家C#语法或结构。我的目标是为大家在不同的情况下使用什么语言构造最好提供指导。
本书面向的读者
本书是为专业的开发人员，也就是那些在日常工作中使用C#的程序员们编写的。本书的阅读前提是读者有面向对象的编程经验，并且至少用过一种C系列语言（C、C++、C#或Java）。有Visual Basic 6背景的开发人员在阅读本书之前，应该先熟悉C#语法和面向对象设计。
另外，读者应该在.NET的重要领域有一些经验：Web Services、ADO.NET、Web Forms和Windows Forms。
为了充分利用本书，大家应该理解.NET环境处理程序集的方式、微软中间语言（MSIL）和可执行代码。C#编译器生成的程序集会包含MSIL，我经常将其简写为IL。加载程序集的时候， JIT（Just In Time）编译器会将MSIL转换为机器可执行的代码。C#编译器确实会执行一些优化，但是JIT编译器会负责处理很多更高效的优化，如内联。在书中，我对各种优化所涉及的过程进行了说明。这种两阶段的编译过程对于在不同情形下哪种构造的表现最佳有着很重要的影响。
本书内容
第1章“C#语言元素”讨论的是C#语法元素和System.Object的核心方法，System.Object是编写每一个类型都要涉及的。声明、语句、算法和System.Object接口，这些都是编写C#代码时必须时刻记住的主题。此外，与值类型和引用类型之间的区别直接相关的条款也都在本章。根据使用的是引用类型（类）还是值类型（结构），很多条款内容都有一些不同。在深入阅读本书之前，我强烈建议大家先阅读有关值类型和引用类型的讨论（条款6~8）。
第2章“.NET资源管理”涵盖了C#和.NET的资源管理问题。大家会学习如何针对.NET管理的执行环境优化资源分配和使用模式。是的，.NET垃圾收集器使我们的工作简单了很多。内存管理是环境的职责，而非开发人员的职责。但是，我们的行为对垃圾收集器在应用程序中的执行效果会产生大的影响。而且，尽管内存不是我们的问题，但管理非内存资源仍然是我们的职责，后者可以通过IDisposable进行处理。在这里，大家可以学习.NET中资源管理的最佳做法。
第3章“使用C#表达设计”从C#的角度讲解了面向对象设计。C#提供了丰富的工具供我们使用。有时候，相同的问题可以用很多不同的方法解决：使用接口、委托、事件或者特性和反射。选用哪一种方式，对系统将来的可维护性会产生很大的影响。选择最佳的设计表示可以帮助程序员们更容易地使用类型。最自然的表示会使我们的意图更加清晰。这样，类型就会比较容易使用，而且不容易误用。第3章中的条款集中讲解了我们所做的设计决定，以及各种C#惯用法最适用的场合。
第4章“创建二进制组件”讲解了组件和语言互操作性。大家将学习如何在不牺牲C#功能的情况下，编写可被其他.NET语言使用的组件。还将学习如何将类细分成组件，来升级应用程序的某些部分。我们应该能在不重新发布整个应用程序的情况下发布组件的新版本。
第5章“使用框架”讲解了.NET框架未充分使用的部分。我看到很多开发人员非常希望创建自己的软件，而不是使用已经构建好的软件。这可能是由.NET框架的体积造成的，也可能因为框架是全新的。这些条款涵盖了框架中那些我曾见过开发人员做重复劳动、而非使用业已存在的功能的部分。通过学习更高效地使用框架，大家可以节省宝贵的时间。
第6章“杂项讨论”以不适合其他分类的条款以及对未来的展望作为全书的结尾。有关C# 2.0、标准、异常安全（exception-safe）的代码、安全和互操作的信息，都可以在这里找到。
关于条款
我写这些条款是为了向大家提供编写C#软件的简洁明了的建议。书中有一些指导方针是通用的，因为它们会影响程序的正确性，如正确初始化数据成员（参见第2章）。有一些指导方针不是很容易理解，并且在.NET社区中引发过很多争论，如是否使用ADO.NET DataSet。我个人认为使用它们可以节省很多时间（参见条款41），其他一些专业的程序员，同时也是我非常尊敬的程序员，对此并不同意。它其实取决于我们正在构建的软件性质。我的立场是尽量节省时间。如果是编写大量在基于.NET和基于Java的系统之间传输信息的软件，DataSet就是个糟糕的主意。在整本书中，我为所做的全部建议都给出了理由。如果其理由并不适用于你碰到的情况，那就不要采纳书中的建议。当建议是普遍适用时，我通常会省略其显而易见的理由：如果不这样做，程序就起不了作用。
版式和代码约定
写编程语言图书的一个困难之处在于，语言设计者用一些英文单词表示非常特殊的新含义，这就导致了一些很难理解的句子。“Develop interfaces with interfaces”就是一个例子。因此，我在使用语言关键字时，都采用了代码体。
本书使用了很多相关的C#术语。在提到类型的成员时，它是指可以成为类型的一部分的任何定义：方法、属性、字段、索引器、事件、枚举或者委托。当应用的只是一种定义时，我会使用一个更加具体的术语。对于书中的许多术语，大家可能熟悉，也可能还不熟悉。当这些术语第一次在正文中出现时，它们会以楷体形式表现，并给出定义。
本书的范例都是简短、专注的代码段，以示范特定条款中的建议。列出它们是为了强调遵循建议的好处。它们并不是可以加入到读者当前程序中的完整范例。大家不能简单地复制代码清单，然后编译它们。所有代码清单我都省略了很多细节。在所有情况下，我们都预设已存在如下常用的using语句：
using System;
using System.IO;
using System.Collections;
using System.Data;
当使用不太常见的命名空间时，我会确保让读者看到相关的命名空间。简短的范例会使用完全限定类名称，而长的范例则会包含不太常用的using语句。
范例中的代码也比较随意。例如，当显示下列代码时：
string s1 = GetMessage( );
如果和论述的内容无关，我可能不会显示GetMessage()例程的主体。当我省略代码时，读者可以假定缺失的方法做的是一些明显且合理的事情。我这样做的目的是为了让我们把焦点聚在特殊的主题上。通过省略和主题无关的代码，我们的注意力就不会分散。这样还能让各个条款保持简短，以使大家能够在短时间内完成学习。
关于C# 2.0
我之所以对新的C# 2.0版本所言甚少，有两个原因。首先，本书中的大部分建议也同样适用于C# 2.0。虽然C# 2.0是一个非常重大的升级版本，但它是建立在C# 1.0基础之上的，且并没有让现如今的建议失效。对于最佳实践有可能发生变化的地方，我已经在文中给出了说明。
第二个原因是现在编写新的C# 2.0功能的高效用法还为时过早。本书的内容是基于我以及我的同事使用C# 1.0的已有经验。我们对于C#2.0中的新功能还没有足够的经验，因而也就不了解能够应用到日常任务中的最佳做法。当在书中编写C# 2.0新功能的高效用法的时机还未成熟时，我并不想误导读者。
建议、反馈及获取本书的更新内容
本书内容基于我的经验以及和同事们的交流。如果读者有不同的经验，或者有任何疑问或意见，我愿洗耳恭听。请通过电子邮件和我联系：wwagner@srtsolutions.com。我会把这些意见放在网上，作为本书的延伸。登录www.srtsolutions.com/EffectiveCSharp，可以看到当前的讨论。
致谢
虽然写作似乎是一件孤独的事情，但本书却是一大群人的成果。我非常幸运，认识两位出色的编辑Stephane Nakib和Joan Murray。Stephane Nakib第一次联系我为Addison Wesley写作是在一年多以前。我当时心存疑虑，因为书店里到处都是.NET和C#方面的书籍。在C# 2.0面世了足够的时间，可以大书特书之前，我一直看不出为C#和.NET再写一本参考书、教程或编程书籍的必要性。我们讨论过好几个想法，话题总是回到写一本有关C#最佳实践的图书。在进行这些讨论的过程中，Stephane告诉我，Scott Meyers开始着手主编一个Effective系列，其风格延续了他的Effective C++系列图书。我买的Scott的三本书都被我翻得非常破旧。我还将它们推荐给了我认识的每一位专业C++程序员。他的写作风格清晰而简明。每一个建议条款都有过硬的理由。Effective丛书是很好的资源，而且其体例使得读者很容易就能记住其中的建议。我认识很多C++开发人员，他们复印了书的目录，并把它钉在书房的墙上，不断提醒自己。Stephane一提到写作Effective C#的想法，我就欣然接受了这个机会。这本书把我曾为C#开发人员给出的所有建议收录在一起。我很荣幸能成为该系列图书的一个作者。和Scott一起工作让我学到了很多东西。我真心希望本书能够像Scott的书提高了我的C++技巧那样，帮助大家提高C#应用技巧。
Stephane帮助落实了写作Effective C#的想法，她审读了提纲和草稿，并在该书的早期写作过程中给予了充分的支持。当她抽身离开的时候，Joan Murray接管了这个项目，并毫无倦怠地负责了原稿的写作管理。Ebony Haight作为编辑助理，在整个过程中提供了不间断的帮助。Krista Hansing完成了所有编辑和转换编程行话的工作。Christy Hackerd完成了所有把Word文档转变为成书的工作。
书中如有错误，应由我来负责。出色的审稿团队修改了绝大多数的错误、冗长和表述不清的问题。最值得一提的是，Brian Noyes、Rob Steel、Josh Holmes和Doug Holland使得最终的正文比初期的草稿更加正确和有用。另外，还要感谢安阿伯计算机学会、大湖区.NET用户组、Greater Lansing用户组和西密歇根州.NET用户组的所有成员，他们听取了有关这些条款的议论，并提供了出色的反馈。
特别要提到的是，Scott Meyers的参与对本书的最终版本有着巨大的积极影响。和他讨论本书的早期草稿，使得我更加明白为什么自己会把Effective C++丛书用得破旧不堪。再小的问题，也逃不过他的眼睛。
我要感谢MyST Technology Partners（myst-technology.com）的Andy Seidl和Bill French。我使用了一个基于MyST的安全博客网址向审稿人公布了各个条款的早期草稿。之后我们向公众公开了部分站点，以便大家能够以在线的格式看到本书的部分内容。登录www.srtsolutions.com/EffectiveCSharp，可以阅读在线版本。
到目前为止，我已经为杂志写了好几年的文章，我要在此感谢那个将我引进门的人：Richard Hale Shaw。他在自己参与创办的杂志《Visual C++开发者》上邀请我这个未经检验的作者开设了一个专栏。如果没有他的帮助，我不会发现自己对写作的热爱。没有他最初给我的帮助，我也不会有机会为Visual Studio杂志、C# Pro或ASP.NET Pro撰稿。
一路走来，我幸运地和不同杂志的很多出色的编辑共过事。我想把他们的名字全都列在这里，但空间不允许。有一个人非提不可，那就是Elden Nelson。我享受与他共事的所有时光，他对我的写作风格产生了很大的积极影响。
我的业务伙伴Josh Holmes和Dianne Marsh，他们容忍了我对公司业务的有限参与，而让我把时间用来写作本书。他们还帮助审阅了我的原稿、想法和条款中的思想。
在整个漫长的写作过程中，我的父母Bill和Alice Wagner“做事要有始有终”的忠告，成为我最终完成本书的唯一原因。
最后也是最重要的，我要感谢我的家人Marlene、Lara、Sarah和Scott。写书会占用大量的业余时间。在我为本书付出了所有时间之后，他们表现出来的却是始终如一的耐心。

Effective C# - 条款1：使用属性代替可访问的数据成员
为什么程序已经可以正常工作了，我们还要改变它们呢？答案就是我们可以让它们变得更好。我们常常会改变所使用的工具或者语言，因为新的工具或者语言更富生产力。如果固守旧有的习惯，我们将得不到期望的结果。对于C#这种和我们已经熟悉的语言（如C++或Java）有诸多共通之处的新语言，情况更是如此。人们很容易回到旧的习惯中去。当然，这些旧的习惯绝大多数都很好，C#语言的设计者们也确实希望我们能够利用这些旧习惯下所获取的知识。但是，为了让C#和公共语言运行库（Common Language Runtime，CLR）能够更好地集成在一起，从而为面向组件的软件开发提供更好的支持，这些设计者们不可避免地需要添加或者改变某些元素。本章将讨论那些在C#中应该改变的旧习惯，以及对应的新的推荐做法。


条款1：使用属性代替可访问的数据成员

C#将属性从其他语言中的一种特殊约定提升成为一种第一等（first-class）的语言特性。如果大家还在类型中定义公有的数据成员，或者还在手工添加get和set方法，请赶快停下来。属性在使我们可以将数据成员暴露为公有接口的同时，还为我们提供了在面向对象环境中所期望的封装。在C#中，属性（property）是这样一种语言元素：它们在被访问的时候看起来好像是数据成员，但是它们却是用方法实现的。

有时候，一些类型成员最好的表示形式就是数据，例如一个客户的名字、一个点的x/y坐标，或者上一年的收入。使用属性我们可以创建一种特殊的接口——这种接口在行为上像数据访问，但却仍能获得函数的全部好处。客户代码[1]对属性的访问就像访问公有变量一样。但实际的实现采用的却是方法，这些方法内部定义了属性访问器的行为。

.NET框架假定我们会使用属性来表达公有数据成员。事实上，.NET框架中的数据绑定类只支持属性，而不支持公有数据成员。这些数据绑定类会将对象的属性关联到用户界面控件（Web控件或者Windows Forms控件）上。其数据绑定机制事实上是使用反射来查找一个类型中具有特定名称的属性。例如下面的代码：

textBoxCity.DataBindings.Add("Text",
      address, "City");

便是将textBoxCity控件的Text属性和address对象的City属性绑定在一起。（有关数据绑定的细节，参见条款38。）如果City是一个公有数据成员，这样的数据绑定就不能正常工作。.NET框架类库（Framework Class Library）的设计者们之所以不支持这样的做法，是因为将数据成员直接暴露给外界不符合面向对象的设计原则。.NET框架类库这样的设计策略从某种意义上讲也是在推动我们遵循面向对象的设计原则。对于C++和Java编程老手，我想特别指出的是这些数据绑定代码并不会去查找get和set函数。在C#中，我们应该忘掉get_和set_这些旧式的约定，而全面采用属性。

当然，数据绑定所应用的类一般都要和用户界面打交道。但这并不意味着属性只在UI（用户界面）逻辑中有用武之地。对于其他类和结构，我们也需要使用属性。随着时间的推移，新的需求或行为往往会影响原来类型的实现，采用属性比较容易能够应对这些变化。例如，我们可能很快就会发现Customer类型不能有一个空的Name。如果我们使用一个公用属性来实现Name，那么只需要在一个地方做更改即可：

public class Customer
{
private string _name;
public string Name
{
    get
    {
      return _name;
    }
    set
    {
      if (( value == null ) ||
        ( value.Length == 0 ))
        throw new ArgumentException( "Name cannot be blank",
          "Name" );
      _name = value;
    }
}
// ……
}

如果使用的是公有数据成员，我们就要寻找并修改所有设置Customer的Name的代码，那将花费大量的时间。

另外，由于属性是采用方法来实现的，因此为它们添加多线程支持就更加容易——直接在get和set方法中提供同步数据访问控制即可：

public string Name
{
get
{
    lock( this )
    {
      return _name;
    }
}
set
{
    lock( this )
    {
      _name = value;
    }
}
}

既然是采用方法来实现的，那么属性也就具有了方法所具有的全部功能。比如，属性可以实现为虚属性：

public class Customer
{
private string _name;
public virtual string Name
{
    get
    {
      return _name;
    }
    set
    {
      _name = value;
    }
}
// 忽略其他实现代码。
}

自然，属性也可以实现为抽象属性，或者作为接口定义的一部分：

public interface INameValuePair
{
object Name
{
    get;
}
object Value
{
    get;
    set;
}
}

最后，我们还可以借助属性的特点来创建const和非const版本的接口：

public interface IConstNameValuePair
{
object Name
{
    get;
}
object Value
{
    get;
}
}

public interface INameValuePair
{
object Value
{
    get;
    set;
}
}

// 上述接口的应用：

public class Stuff : IConstNameValuePair, INameValuePair
{
private string _name;
private object _value;

#region IConstNameValuePair Members

public object Name
{
    get
    {
      return _name;
    }
}

object IConstNameValuePair.Value
{
    get
    {
      return _value;
    }
}

#endregion

#region INameValuePair Members

public object Value
{
    get
    {
      return _value;
    }
    set
    {
    _value = value;
    }
}

#endregion
}

属性在C#中已经成为一项比较完善的、第一等的语言元素。我们可以针对成员函数做的任何事情，对于属性也同样适用。毕竟，属性是对访问／修改内部数据的方法的一种扩展。

我们知道，属性访问器在编译后事实上是两个分离的方法。在C# 2.0中，我们可以为一个属性的get访问器和set访问器指定不同的访问修饰符。这使得我们可以更好地控制属性的可见性。

// 合法的C# 2.0代码:

public class Customer
{
private string _name;
public virtual string Name
{
    get
    {
      return _name;
    }
    protected set
    {
      _name = value;
    }
}

// 忽略其他实现代码。
}

C#的属性语法扩展自简单的数据字段。如果类型接口需要包含一些索引数据项，则可以使用一种称作索引器（indexer）的类型成员。索引器在C#中又称含参属性（parameterized property）。这种“使用属性来返回一个序列中的数据项”的做法对于很多场合非常有用，下面的代码展示了这一用法：

public int this [ int index ]
{
get
{
    return _theValues [ index ] ;
}
set
{
    _theValues[ index ] = value;
}
}

// 访问索引器：

int val = MyObject[ i ];

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

public Address this [ string name ]
{
get
{
    return _theValues[ name ] ;
}
set
{
    _theValues[ name ] = value;
}
}

与C#中的多维数组类似，我们也可以创建“多维索引器”——其每一维上的参数类型可以相同，也可以不同。

public int this [ int x, int y ]
{
get
{
    return ComputeValue( x, y );
}
}

public int this[ int x, string name ]
{
get
{
    return ComputeValue( x, name );
}
}

注意所有的索引器都使用this关键字来声明。我们不能为索引器指定其他的名称。因此，在每个类型中，对于同样的参数列表，我们只能有一个索引器。

属性显然是一个好东西，相较于以前的各种访问方式来讲，它的确是一个进步。但是，有些读者可能会有如下的想法：刚开始先使用数据成员，之后如果需要获得属性的好处时，再考虑将数据成员替换为属性。这种做法听起来似乎有道理，但实际上是错的。让我们来看下面一段代码：

// 使用公有数据成员，不推荐这种做法：

public class Customer
{
public string Name;

// 忽略其他实现代码。

}

这段代码描述了一个Customer类，其内包含一个成员Name。我们可以使用成员访问符来获取／设置其Name的值：

string name = customerOne.Name;

customerOne.Name = "This Company, Inc.";

这段代码非常简洁和直观。有人据此就认为以后如果有需要，再将Customer类的数据成员Name替换为属性就可以了，而使用Customer类型的代码无需做任何改变。这种说法从某种程度上来讲是对的。

属性在被访问的时候和数据成员看起来没有什么差别。这正是C#引入新的属性语法的一个目标。但属性毕竟不是数据，访问属性和访问数据产生的是不同的MSIL。前面那个Customer类型的Name字段在编译后将产生如下MSIL代码：

.field public string Name

而访问该字段的部分编译后的MSIL代码如下：

ldloc.0

ldfld      string NameSpace.Customer::Name

stloc.1

向该字段存储数据的部分编译后的MSIL代码如下：

ldloc.0

ldstr      "This Company, Inc."

stfld      string NameSpace.Customer::Name

大家不必担忧，我们不会整天围绕着IL代码转。为了让大家清楚“在数据成员和属性之间做改变会打破二进制兼容性”，在这里展示一下IL代码还是很重要的。我们再来看下面的Customer类型实现，这次我们采用了属性的方案：

public class Customer
{
private string _name;
public string Name
{
    get
    {
      return _name;
    }
    set
    {
      _name = value;
    }
}

// 忽略其他实现代码。

}

当我们在C#中访问Name属性时，使用的语法和前面访问字段的语法一模一样。

string name = customerOne.Name;

customerOne.Name = "This Company, Inc.";

但是，C#编译器对于两段相同的C#代码产生的却是完全不同的MSIL代码。我们来看新版Customer类型的Name属性编译后的MSIL:

.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 string
        get_Name() cil managed
{
// 代码长度 11 (0xb)
.maxstack 1
.locals init ([0] string CS$00000003$00000000)
IL_0000: ldarg.0
IL_0001: ldfld      string NameSpace.Customer::_name
IL_0006: stloc.0
IL_0007: br.s      IL_0009
IL_0009: ldloc.0
IL_000a: ret
} // 方法Customer:get_Name结束。

.method public hidebysig specialname instance void
        set_Name(string 'value') cil managed
{
// 代码长度 8 (0x8)
.maxstack 2
IL_0000: ldarg.0
IL_0001: ldarg.1
IL_0002: stfld      string NameSpace.Customer::_name
IL_0007: ret
} // 方法Customer::set_Name结束。

在将属性定义从C#代码转换为MSIL的过程中，有两点需要我们注意：首先，.property指示符定义了属性的类型，以及实现属性get访问器和set访问器的两个函数。这两个函数被标记为hidebysig和specialname。对我们来说，这两个标记意味着它们所修饰的函数不能直接在C#源代码中被调用，也不被认为是类型正式定义的一部分。要访问它们，我们只能通过属性。

当然，大家对于属性定义产生不同的MSIL应该早有预期。更重要的是，对属性所做的get和set访问的客户代码编译出来的MSIL也不同：

// get

ldloc.0

callvirt instance string NameSpace.Customer:get_Name()

stloc.1

// set

ldloc.0

ldstr      "This Company, Inc."

callvirt instance void NameSpace.Customer::set_Name(string)

大家看到了，同样是访问客户（Customer）名称（Name）的C#源代码，由于所使用的Name成员不同——属性或者数据成员，编译后产生出的MSIL指令也不同。尽管访问属性和访问数据成员使用的是同样的C#源代码，但是C#编译器却将它们转换为不同的IL代码。

换句话说，虽然属性和数据成员在源代码层次上是兼容的，但是在二进制层次上却不兼容。这意味着如果将一个类型的公有数据成员改为公有属性，那么我们必须重新编译所有使用该公有数据成员的C#代码。本书第４章“创建二进制组件”讨论了二进制组件的相关细节，但是在此之前大家要清楚，将一个数据成员改为属性会破坏二进制兼容性。如果这样的程序集已经被部署，那么升级它们的工作将变得非常麻烦。

看了属性产生的IL代码之后，有读者可能想知道使用属性和使用数据成员在性能上有什么差别。虽然使用属性不会比使用数据成员的代码效率更快，但是它也不见得就会比使用数据成员的代码慢，因为JIT编译器会对某些方法调用（包括属性访问器）进行内联处理。如果JIT编译器对属性访问器进行了内联处理，那么属性和数据成员的效率将没有任何差别。即使属性访问器没有被内联，实际的效率差别相对于函数调用的成本来讲也是可以忽略不计的。只有在很少的一些情况下，这种差别才值得我们注意。

综上所述，只要打算将数据暴露在类型的公有接口或者受保护接口中，我们都应该使用属性来实现。对于具有序列或者字典特征的类型，则应该采用索引器。所有的数据成员都应一律声明为私有。使用属性的好处显而易见：我们可以得到更好的数据绑定支持，我们可以更容易地在将来对其访问方法的实现做任何改变。将变量封装在属性中只不过增加一两分钟代码录入时间。如果刚开始使用数据成员，后来又发现需要使用属性，这时再来修改的成本将是几个小时。今天的一点投入，会为明天节省许多时间。

Effective C# - 条款2：运行时常量（readonly）优于编译时常量（const）

条款2：运行时常量（readonly）优于编译时常量（const）


C#语言有两种不同的常量机制：一种为编译时（compile-time）常量，一种为运行时（runtime）常量。两种常量有着非常迥异的行为，使用不正确会导致程序的性能下降或者出现错误。这两种代价，哪一个都没有人愿意承担，但是如果必须承担一个，那么“慢、但是能够正确运行的”程序总比“快、但是可能出错的”程序要好。因此，我们说运行时常量优于编译时常量。编译时常量比运行时常量稍微快一点，但却缺乏灵活性。只有在性能非常关键，并且其值永远不会改变的情况下，我们才应该使用编译时常量。


在C#中，我们使用readonly关键字来声明运行时常量，用const关键字来声明编译时常量。
// 编译时常量：
public const int _Millennium = 2000;
// 运行时常量：
public static readonly int _ThisYear = 2004;


编译时常量与运行时常量行为的不同处在于它们的访问方式。编译时常量在编译后的结果代码中会被替换为该常量的值，例如下面的代码：
if ( myDateTime.Year == _Millennium )
其编译后的IL和下面的代码编译后的IL一样：
if ( myDateTime.Year == 2000 )
运行时常量的值则在运行时被计算。对于使用运行时常量的代码，其编译后的IL将维持对readonly变量（而非它的值）的引用。

这种差别会为我们使用两种常量类型带来一些限制。编译时常量只可以用于基元类型（包括内建的整数类型和浮点类型）、枚举类型或字符串类型。因为只有这些类型才允许我们在初始化器中指定有意义的常量值[2]。在使用这些常量的代码编译后得到的IL代码中，常量将直接被替换为它们的字面值（literal）。例如，下面的代码就不会通过编译。事实上，C#不允许我们使用new操作符来初始化一个编译时常量，即使被初始化的常量类型为一个值类型。
// 下面的代码不会通过编译，但是换成readonly就可以：
private const DateTime _classCreation = new
DateTime( 2000, 1, 1, 0, 0, 0 );
编译时常量仅限于数值和字符串。只读（read-only）字段之所以也被称作一种常量，是因为它们的构造器一旦被执行，我们将不能对它们的值做任何修改。与编译时常量不同的地方在于，只读字段的赋值操作发生在运行时，因此它们具有更多的灵活性。比如，只读字段的类型就没有任何限制。对于只读字段，我们只能在构造器或者初始化器中为它们赋值。在上面的代码中，我们可以声明readonly的DateTime结构变量，但是却不能声明const的DateTime结构变量。
我们可以声明readonly的实例常量，从而为一个类型的每个实例存储不同的值。但是const修饰的编译时常量默认就被定义为静态常量。
我们知道，运行时常量和编译时常量最重要的区别就在于运行时常量值的辨析发生在运行时，而编译时常量值的辨析发生编译时。换言之，使用运行时常量编译后的IL代码引用的是readonly变量，而非它的值；而使用编译时常量编译后的IL代码将直接引用它的值——就像我们直接在代码中使用常量值一样。即使我们使用的是数值常量并跨程序集引用，情况也是一样：如果在程序集A中引用程序集B中的常量，那么编译后程序集A中出现的那个常量将被它的值所替换。这种差别对于代码的维护性而言有着相当的影响。

编译时常量与运行时常量被辨析的方式影响着运行时的兼容性。假设我们在一个名为Infrastructure 的程序集中分别定义了一个const字段和一个readonly字段：
public class UsefulValues
{
public static readonly int StartValue = 5;
public const int EndValue = 10;
}
在另外一个程序集Application中，我们又引用着这些值：
for ( int i = UsefulValues.StartValue;
i < UsefulValues.EndValue;
i++ )
Console.WriteLine( "value is {0}", i );
如果我们运行上面的代码，将得到以下输出：
Value is 5
Value is 6
...
Value is 9


假设随着时间的推移，我们又发布了一个新版的Infrastructure程序集：
public class UsefulValues
{
public static readonly int StartValue = 105;
public const int EndValue = 120;
}


我们将新版的Infrastructure程序集分发出去，但并没有重新编译Application程序集。我们期望得到如下的输出：
Value is 105
Value is 106
...
Value is 119


但实际上，我们却没有得到任何输出。因为现在那个循环语句将使用105作为它的起始值，使用10作为它的结束条件。其根本原因在于C#编译器在第一次编译Application程序集时，将其中的EndValue替换成了它对应的常量值10。而对于StartValue来说，由于它被声明为readonly，所以它的辨析发生在运行时。因此，Application程序集在没有被重新编译的情况下，仍然可以使用新的StartValue值。为了改变所有使用readonly常量的客户代码的行为，简单地安装一个新版的Infrastructure 程序集就足够了。“更改一个运行时常量的值”应该被视作对类型接口的更改，其后果是我们必须重新编译所有引用该常量的代码。“更改一个公有的运行时常量的值”应该被视作对类型实现的更改，它与其客户代码在二进制层次上是兼容的。大家看看上述代码中的循环编译后的MSIL，就会对这里所谈的更加清楚了：
IL_0000: ldsfld int32 Chapter1.UsefulValues::StartValue
IL_0005: stloc.0
IL_0006: br.s IL_001c
IL_0008: ldstr "value is {0}"
IL_000d: ldloc.0
IL_000e: box [mscorlib]System.Int32
IL_0013: call void [mscorlib]System.Console::WriteLine
(string,object)
IL_0018: ldloc.0
IL_0019: ldc.i4.1
IL_001a: add
IL_001b: stloc.0
IL_001c: ldloc.0
IL_001d: ldc.i4.s 10
IL_001f: blt.s IL_0008


大家可以在这段MSIL代码的顶端看到StartValue的确是被动态加载的，而在其末尾可以看到结束条件被硬编码（hard-code）为10。
不过，有时候有些值确实可以在编译时确定，这时候就应该使用编译时常量。例如，考虑在对象的序列化形式（有关对象序列化，可参见条款25）中使用一组常量来区分不同版本的对象。其中，标记特殊版本号的持久化数据应该采用编译时常量，因为它们的值永远不会改变。但是标记当前版本号的数据应该采用运行时常量，因为它的值会随着每个不同的版本而改动。
private const int 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( SerializationInfo 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,
SerializationFormatter =true ) ]
void ISerializable.GetObjectData( SerializationInfo inf,
StreamingContext cxt )
{
// 使用运行时常量来标记当前版本号：
inf.AddValue( "VERSION", CURRENT_VERSION );
// 写入其他元素……
}

使用const较之于使用readonly的唯一好处就是性能：使用已知常量值的代码效率要比访问readonly值的代码效率稍好一点。但是这其中的效率提升是非常小的，大家应该和其所失去的灵活性进行一番权衡比较。在打算放弃灵活性之前，一定要对两者的性能差别做一个评测。
综上所述，只有当某些情况要求变量的值必须在编译时可用，才应该考虑使用const，例如：特性（attribute）类的参数，枚举定义，以及某些不随组件版本变化而改变的值。否则，对于其他任何情况，都应该优先选择readonly常量，从而获得其所具有的灵活性。

Effective C#中文版 - 条款3：操作符is或as优于强制转型

条款3：操作符is或as优于强制转型

C#是一门强类型语言。一般情况下，我们最好避免将一个类型强制转换为其他类型。但是，有时候运行时类型检查是无法避免的。相信大家都写过很多以System.Object类型为参数的函数，因为.NET框架预先为我们定义了这些函数的签名。在这些函数内部，我们经常要把那些参数向下转型为其他类型，或者是类，或者是接口。对于这种转型，我们通常有两种选择：使用as操作符，或者使用传统C风格的强制转型。另外还有一种比较保险的做法：先使用is来做一个转换测试，然后再使用as操作符或者强制转型。

正确的选择应该是尽可能地使用as操作符，因为它比强制转型要安全，而且在运行时层面也有比较好的效率。需要注意的是，as和is操作符都不执行任何用户自定义的转换。只有当运行时类型与目标转换类型匹配时，它们才会转换成功。它们永远不会在转换过程中构造新的对象。

我们来看一个例子。假如需要将一个任意的对象转换为一个MyType的实例。我们可能会像下面这样来做：

object o = Factory.GetObject( );

// 第一个版本：

MyType t = o as MyType;

if ( t != null )
{
// 处理t, t现在的类型为MyType。
} else
{
// 报告转型失败。
}

或者，也可以像下面这样来做：

object o = Factory.GetObject( );

// 第二个版本：

try {
MyType t;
t = ( MyType ) o;
if ( t != null )
{
// 处理t, t现在的类型为MyType
} else

{
// 报告空引用失败。
}

} catch

{
// 报告转型失败。
}

相信大家都同意第一个版本的转型代码更简单，也更容易阅读。其中没有添加额外的try/catch语句，因此也就避免了其带来的负担。注意，第二个版本中除了要捕捉异常外，还要对null的情况进行检查，因为如果o本来就是null，那么强制转型可以将它转换成任何引用类型。但如果是as操作符，且被转换对象为null，那么执行结果将返回null。因此，如果使用强制转型，我们既要检查其是否为null，还要捕捉异常。如果使用as操作符，我们只需要检查返回的引用是否为null就可以了。

cast和as操作符之间最大的区别就在于如何处理用户自定义的转换。操作符as和is都只检查被转换对象的运行时类型，并不执行其他的操作。如果被转换对象的运行时类型既不是所转换的目标类型，也不是其派生类型，那么转型将告失败。但是，强制转型则会使用转换操作符来执行转型操作，这包括任何内建的数值转换。例如，将一个long类型强制转换为一个short类型将会导致部分信息丢失。

在我们使用用户自定义的转换时，也会有同样的问题，来看下面的代码：

public class SecondType

{

private MyType _value;

// 忽略其他细节。

// 转换操作符。

// 将SecondType 转换为MyType，参见条款29。[4]

public static implicit operator

MyType( SecondType t )

{

return t._value;

}

}

假设下面第一行代码中的Factory.GetObject()返回的是一个SecondType对象：

object o = Factory.GetObject( );

// o 为一个SecondType:

MyType t = o as MyType; // 转型失败，o的类型不是MyType。

if ( t != null )

{

// 处理t, t现在的类型为MyType。

} else

{

// 报告转型失败。

}

// 第二个版本：

try {

MyType t1;

t1 = ( MyType ) o; // 转型失败，o的类型不是MyType。

if ( t1 != null )

{

// 处理t1, t1现在的类型为MyType。

} else

{

// 报告空引用失败。

}

} catch

{

// 报告转型失败。

}

两个版本的转型操作都失败了。大家应该还记得我前面说过强制转型会执行用户自定义的转换，有读者据此认为强制转型的那个版本会成功。这么想本身没有错误，只是编译器在产生代码时依据的是对象o的编译时类型。编译器对于o的运行时类型一无所知——编译器只知道o的类型是System.Object。因此编译器只会检查是否存在将System.Object转换为MyType的用户自定义转换。它会到System.Object类型和MyType类型的定义中去做这样的检查。由于没有找到任何用户自定义转换，编译器将产生代码来检查o的运行时类型，并将其和MyType进行比对。由于o的运行时类型为SecondType，因此转型将告失败。编译器不会检查在o的运行时类型SecondType和MyType之间是否存在用户自定义的转换。

当然，如果将上述代码做如下修改，转换就会成功执行：

object o = Factory.GetObject( );

// 第三个版本：

SecondType st = o as SecondType;

try {

MyType t;

t = ( MyType ) st;

if ( t != null )

{

// 处理t, t现在的类型为MyType。

} else

{

// 报告空引用失败。

}

} catch

{

条款3：操作符is或as优于强制转型　　24


// 报告转型失败。

}

在正式的开发中，我们绝不能写如此丑陋的代码，但它却向我们揭示了问题的所在。虽然大家永远都不可能像上面那样写代码，但可以使用一个以System.Object类型为参数的函数，让该函数在内部执行正确的转换。

object o = Factory.GetObject( );

DoStuffWithObject( o );

private void DoStuffWithObject( object o2 )

{

try {

MyType t;

t = ( MyType ) o2; // 转型失败，o的类型不是MyType

if ( t != null )

{

// 处理t, t现在的类型为MyType。

} else

{

// 报告空引用失败。

}

} catch

{

// 报告转型失败。

}

}

记住，用户自定义的转换操作符只作用于对象的编译时类型，而非运行时类型上。至于o2的运行时类型和MyType之间是否存在转换，并不重要。事实上，编译器对此并不了解，也不关心。对于下面的语句，如果st的声明类型不同，会有不同的行为：

t = ( MyType ) st;

但对于下面的语句，不管st的声明类型是什么，都会产生同样的结果[5]。因此，我们说as操作符要优于强制转型——它的转型结果相对比较一致。

但如果as操作符两边的类型没有继承关系，即使存在用户自定义转换操作符，也会产生编译时错误。例如，下面的语句：

t = st as MyType;

我们已经知道在转型的时候应该尽可能地使用as操作符。下面我们来谈谈一些不能使用as操作符的情况。首先，as操作符不能应用于值类型。例如，下面的代码编译的时候就会报错：

object o = Factory.GetValue( );

int i = o as int; // 不能通过编译。

这是因为int是一个值类型，所以不可以为null。如果o不是一个整数，那这个i里面还能存放什么呢？存入的任何值都必须是有效的整数，所以as不能和值类型一起使用。那就只能使用强制转型了：

object o = Factory.GetValue( );

int i = 0;

try {

i = ( int ) o;

} catch

{

i = 0;

}

但是，我们也并非只能这样。我们还可以使用is语句来避免其中对异常的检查或者强制转型：

object o = Factory.GetValue( );

int i = 0;

if ( o is int )

i = ( int ) o;

如果o不是某个其他可以转换为int的类型，例如double，那么is操作符将返回false。如果o的值为null，is操作符也将返回false。

只有当我们不能使用as操作符来进行类型转换时，才应该使用is操作符。否则，使用is将会带来代码的冗余：

// 正确, 但是冗余：

object o = Factory.GetObject( );

MyType t = null;

if ( o is MyType )

t = o as MyType;

上面的代码和下面的代码事实上是一样的：

// 正确, 但是冗余：

object o = Factory.GetObject( );

MyType t = null;

if ( ( o as MyType ) != null )

t = o as MyType;

这种做法显然既不高效，也显得冗余。如果我们打算使用as来做转型，那么再使用is检查就没有必要了。直接将as操作符的运算结果和null进行比对就可以了，这样比较简单。

既然我们已经明白了is操作符、as操作符和强制转型之间的差别，那么大家猜猜看foreach循环语句中使用的是哪个操作符来执行类型转换呢？

public void UseCollection( IEnumerable theCollection )

{

foreach ( MyType t in theCollection )

t.DoStuff( );

}

答案是强制转型。事实上，下面的代码和上面foreach语句编译后的结果是一样的：

public void UseCollection( IEnumerable theCollection )

{

IEnumerator it = theCollection.GetEnumerator( );

while ( it.MoveNext( ) )

{

MyType t = ( MyType ) it.Current;

t.DoStuff( );

}

}

之所以使用强制转型，是因为foreach语句需要同时支持值类型和引用类型。无论转换的目标类型是什么，foreach语句都可以展现相同的行为。但是，由于使用的是强制转型，foreach语句可能产生BadCastException异常[6]。

由于IEnumerator.Current返回的是System.Object，而Object中又没有定义任何的转换操作符，因此转换操作符就不必考虑了。如果集合中是一组SecondType对象，那么运用在UseCollection()函数中将会出现转型失败，因为foreach语句使用的是强制转型，而强制转型并不关心集合元素的运行时类型。它只检查在System.Object类（由IEnumerator.Current返回的类型）和循环变量的声明类型MyType之间是否存在转换。

最后，有时候我们可能想知道一个对象的确切类型，而并不关心它是否可以转换为另一种类型。如果一个类型继承自另一个类型，那么is操作符将返回true。使用System.Object的GetType()方法，可以得到一个对象的运行时类型。利用该方法可以对类型进行比is或as更为严格的测试，因为我们可以拿它所返回的对象的类型和一个具体的类型做对比。

再来看下面的函数：

public void UseCollection( IEnumerable theCollection )

{

foreach ( MyType t in theCollection )

t.DoStuff( );

}

如果创建了一个继承自MyType的类NewType，那便可以将一组NewType对象集合应用在UseCollection函数中。

public class NewType : MyType

{

// 忽略实现细节。

}

如果我们打算编写一个函数来处理所有与MyType类型兼容的实例对象，那么UseCollection函数所展示的做法就挺好。但如果打算编写的函数只处理运行时类型为MyType的对象，那就应该使用GetType()方法来对类型做精确的测试。我们可以将这种测试放在foreach循环中。运行时类型测试最常用的地方就是相等判断（参见条款9）。对于绝大多数其他的情况，as和is操作符提供的.isinst比较[7]在语义上都是正确的。

条款4：使用Conditional特性代替#if条件编译


#if/#endif条件编译常用来由同一份源代码生成不同的结果文件，最常见的有debug版和release版。但是，这些工具在具体应用中并不是非常得心应手，因为它们太容易被滥用了，使用它们创建的代码通常都比较难理解，且难以调试。C#语言的设计者们对这种问题的解决方案是创建更好的工具，以达到为不同环境创建不同机器码的目的。C#为此添加了一个Conditional特性，该特性可以标示出某种环境设置下某个方法是否应该被调用。使用这种方式来描述条件编译要比#if/#endif更加清晰。由于编译器理解Conditional特性，所以它可以在Conditional特性被应用时对代码做更好的验证。Conditional特性应用在方法这一层次上，因此它要求我们将条件代码以方法为单位来表达。当需要创建条件代码块时，我们应该使用Conditional特性来代替传统的#if/#endif。

大多数程序老手都使用过条件编译来检查对象的前置条件和后置条件。例如，编写一个私有方法来检查所有类与对象的不变式（invariant）[8]，然后将这样的方法进行条件编译，从而让其只出现在debug版本的程序中。

private void CheckState( )

{

// 老式的做法：

#if DEBUG

Trace.WriteLine( "Entering CheckState for Person" );

// 获取正在被调用函数的名称：

string methodName =

new StackTrace( ).GetFrame( 1 ).GetMethod( ).Name;



Debug.Assert( _lastName != null,

methodName,

"Last Name cannot be null" );

Debug.Assert( _lastName.Length > 0,

methodName,

"Last Name cannot be blank" );

Debug.Assert( _firstName != null,

methodName,

"First Name cannot be null" );

Debug.Assert( _firstName.Length > 0,

methodName,

"First Name cannot be blank" );

Trace.WriteLine( "Exiting CheckState for Person" );

#endif

}

条件编译#if和#endif使得最终release版本中的CheckState()成为一个空方法，但它在release版和debug版中都将得到调用。虽然在release版中，CheckState()什么也不做，但是我们必须为方法的加载、JIT编译和调用付出成本。

就正确性而言，这种做法一般没什么问题，但有时候还是可能会在release版本中导致一些诡异的bug。下面的代码展示了使用#if和#endif条件编译时可能常犯的错误：

public void Func( )

{

string msg = null;

#if DEBUG

msg = GetDiagnostics( );

#endif

Console.WriteLine( msg );

}

上面的代码在debug版本中运行得很好，但是放到release版本中就会输出一个空行。输出一个空行本身没有什么，但这毕竟不是我们本来的意图。我们自己搞糟的事情，编译器也帮不上什么忙，因为我们把属于程序主逻辑的代码和条件编译代码混在一起了。在源代码中随意地使用#if和#endif将使我们很难诊断不同版本间的行为差别。

C#为此提出了一种更好的选择：Conditional特性。使用Conditional特性，我们可以将一些函数隔离出来，使得它们只有在定义了某些环境变量或者设置了某个值之后才能发挥作用。Conditional特性最常用的地方就是将代码改编为调试语句。.NET框架已经为此提供了相关的功能支持。下面的代码展示了Conditional特性的工作原理，以及适用场合。

构建Person对象时，我们一般会添加如下的方法来验证对象的不变式：

private void CheckState( )

{

// 获取正在被调用函数的名称：

string methodName =

new StackTrace( ).GetFrame( 1 ).GetMethod( ).Name;

Trace.WriteLine( "Entering CheckState for Person:" );

Trace.Write( "\tcalled by " );

Trace.WriteLine( methodName );

Debug.Assert( _lastName != null,

methodName,

"Last Name cannot be null" );

Debug.Assert( _lastName.Length > 0,

methodName,

"Last Name cannot be blank" );

Debug.Assert( _firstName != null,

methodName,

"First Name cannot be null" );

Debug.Assert( _firstName.Length > 0,

methodName,

"First Name cannot be blank" );

Trace.WriteLine( "Exiting CheckState for Person" );

}

有些读者可能对上面代码中的一些库函数还不够熟悉，我们来简单介绍一下。StackTrace类使用反射（reflection，参见条款43）来获取当前正被调用的方法名。其代价相当高，但它可以极大地简化我们的工作，例如帮助我们获取有关程序流程的信息。在上面的代码中，使用它，我们便可以得到正被调用的方法名称为CheckState。其余的方法在另外两个类中，分别为System.Diagnostics.Debug和System.Diagnostics.Trace。Debug.Assert方法用于测试某个条件，如果该条件错误，程序将被终止，其他参数定义的消息也将被打印出来。Trace.WriteLine方法则会把诊断信息打印到调试控制台上。因此，如果有Person对象状态无效，CheckState方法将会显示信息，并终止程序。我们可以将其作为前置条件和后置条件，在所有的公有方法和受保护方法中调用它。

public string LastName

{

get

{

CheckState( );

return _lastName;

}

set

{

CheckState( );

_lastName = value;

CheckState( );

}

}

当首次试图将LastName属性设置为空字符串或者null时，CheckState将引发一个断言错误。这样我们就会修正set访问器以检查传递给LastName的参数。这正是我们想要的功能。

但在每个公有函数中都做这样的额外检查显然比较浪费时间，我们可能只希望其出现在调试版本中。这就需要Conditional特性了：

[ Conditional( "DEBUG" ) ]

private void CheckState( )

{

// 代码保持不变。

}

应用了Conditional特性之后，C#编译器只有在检测到DEBUG环境变量时，才会产生对CheckState方法的调用。Conditional特性不会影响CheckState()方法的编译，它只会影响对该方法的调用。如果定义有DEBUG符号，上面的LastName属性将变为如下的代码：

public string LastName

{

get

{

CheckState( );

return _lastName;

}

set

{

CheckState( );

_lastName = value;

CheckState( );

}

}

否则，将得到如下代码：

public string LastName

{

get

{

return _lastName;

}

set

{

_lastName = value;

}

}

无论是否定义有DEBUG符号，CheckState()方法的方法体都维持不变，它都会被C#编译器处理，并生成到结果程序集中。这个例子其实也向大家展示了C#编译器的编译过程与JIT编译过程之间的区别。这种做法看起来也会带来一点效率损失，但是其中耗费的成本仅仅是磁盘空间。如果没有被调用，CheckState()方法并不会加载到内存中并进行JIT编译。将CheckState()方法生成到程序集中产生的影响是非常微不足道的。这种策略耗费很小的性能，换来的却是灵活性。如果感兴趣的话，大家可以查看.NET框架类库中的Debug类来对此获得更深的理解。在每个安装有.NET框架的机器上，System.dll程序集中都包含有Debug类中所有方法的代码。当调用这些方法的代码被编译时，系统环境变量将决定这些方法是否被调用。

我们创建的方法也可以依赖于多个环境变量。当我们应用多个Conditional特性时，它们之间的组合关系将为“或（OR）”。例如，下面的CheckState方法被调用的条件为定义有DEBUG或者TRACE环境变量：

[ Conditional( "DEBUG" ),

Conditional( "TRACE" ) ]

private void CheckState( )

要创建一个使用“与（AND）”关系的构造，我们需要自己在源代码中定义预处理符号：

#if ( VAR1 && VAR2 )

#define BOTH

#endif

是的，要创建一个依赖于多个环境变量的条件程序，我们不得不回到使用#if的老式做法中去。不过所有#if都只不过是创建新的符号而已，我们应该避免将可执行代码放在其中。

Conditional特性只可以应用在整个方法上。另外需要注意的是，任何一个使用Conditional特性的方法只能返回void类型。

我们不能在一个方法内的代码块上应用Conditional特性，也不可以在有返回值的方法上应用Conditional特性。为了应用Conditional特性，我们需要将具有条件性的行为单独放到一个方法中。虽然我们仍然需要注意那些Conditional方法可能给对象状态带来的负面效应，但Conditional特性的隔离策略总归要比#if/#endif好得多。使用#if和#endif代码块，我们很有可能会错误地删除一些重要的方法调用或者赋值语句。


上面的例子使用了DEBUG或者TRACE这样的预定义符号，但我们也可以将其扩展到我们自己定义的符号上。Conditional特性可以被任何方式定义的符号所控制，例如编译器命令行，操作系统shell的环境变量，或者源代码pragma。

综上所述，使用Conditional特性比使用#if/#endif产生的IL代码更有效率。同时，将其限制在函数层次上可以清晰地将条件性的代码分离出来，从而使我们的代码具有更好的结构。另外，C#编译器也为此提供了很好的支持，从而帮助我们避免以前使用#if或#endif时常犯的错误。

条款5：总是提供ToString()方法


System.Object.ToString()恐怕是.NET中最常用的方法了。应该为我们的类的所有客户代码提供一个合理的版本，否则这些代码就只能使用我们的类的一些属性来自己定制可读的表示了。类型的字符串表示非常有用，可以在很多地方向用户显示对象的有关信息，例如在Windows Forms上、Web Forms上、控制台输出窗口中，以及调试环境中。为此，我们创建的每一个类型都应该重写Object类的ToString()方法。如果创建的是更复杂的类型，则应该实现Iformattable.ToString()方法。如果我们没有重写该方法，或者写得不够好，那么使用它们的客户代码就要自己想办法修补了。

System.Object默认提供的ToString()方法会返回类型的名称。这样的信息一般没有什么用处，像"Rect"、"Point"、"Size"这样的字符串大多都不是我们希望显示给用户的。但如果我们不重写Object的ToString()方法，用户看到的就将是这些。我们只需要写一次，但是客户将享用无数次。一点点付出，就可以让很多人（包括我们自己）受益。

让我们来看看重写System.Object.ToString()这个最简单的需求。该方法主要的功能就是为类型提供一个最常用的文本表示。例如，考虑下面这个具有三个字段的Customer类：

public class Customer

{

private string _name;

private decimal _revenue;

private string _contactPhone;

}

如果不提供重写的版本，Customer将继承Object类的ToString()方法，也就是返回一个"Customer"字符串。这个字符串实在没有什么用处。即使ToString()方法只应用于调试的目的，它也应该输出一个更有意义的字符串。我们重写的时候应该尽量考虑客户所希望的表示。就Customer类来说，返回_name是一个不错的选择：

public override string ToString()

{

return _name;

}

即使大家不遵循本条款中的其他建议，也要遵循这里所展示的实践。它可以节省很多人的时间。在我们为Customer类重写了ToString()方法之后，该类的对象将可以更容易地添加到Windows Forms控件、Web Forms控件或者控制台上。.NET FCL在将对象显示到各个控件（如Combo Box、List Box、Text Box等）上时，使用的就是Object.ToString()的重写版本。如果我们在Windows Forms或者Web Forms上创建了一个Customer对象的列表，其文本显示将为Customer的名称（_name）。System.Console.WriteLine()方法、System.String.Format()方法等内部也都调用到了ToString()方法。只要当.NET FCL需要获取Customer的字符串表示时，我们的Customer类型都将以其名称（_name）来响应。仅仅提供一个具有三行代码的方法，就可以处理所有这些基本的需求。

虽然简单的ToString()方法很多时候已经可以满足我们的需求，但有时候，我们还需要功能更强的方法。上述Customer类型有三个字段：_name、_revenue和_contactPhone，而我们仅使用了_name一个字段。我们可以通过实现IFormattable接口来解决这个问题。IFormattable接口包含了一个重载的ToString()方法，它允许我们为类型指定某种格式信息。当我们需要为类型创建不同形式的字符串输出时，这个接口非常有用。Customer类型就是一个例子。比如，有些用户可能希望创建一个报表，在其中以表格的形式包含客户的名称和上一年的收入。IFormattable.ToString()方法允许用户为我们的类型指定某种格式的字符串输出。其签名如下：

string System.IFormattable.ToString( string format,

IFormatProvider formatProvider )

我们可以使用格式字符串来为我们的类型指定自己的格式。比如，使用特定的字符来表示某种格式信息。在Customer类型的例子中，我们可以使用n来表示name，使用r来表示revenue，使用p来表示phone。另外，还可以指定这些字符的组合形式。下面的代码展示了一种可能的做法：

#region IFormattable Members

// 所支持的格式：

// 用n 表示name。

// 用r 表示revenue。

// 用p 表示contact phone。

// 同时支持组合格式: nr、np、npr等。

// "G" 表示通用格式。

string System.IFormattable.ToString( string format,

IFormatProvider formatProvider )

{

if ( formatProvider != null )

{

ICustomFormatter fmt = formatProvider.GetFormat(

this.GetType( ) )

as ICustomFormatter;

if ( fmt != null )

return fmt.Format( format, this, formatProvider );

}

switch ( format )

{

case "r":

return _revenue.ToString( );

case "p":

return _contactPhone;

case "nr":

return string.Format( "{0,20}, {1,10:C}",

_name, _revenue );

case "np":

return string.Format( "{0,20}, {1,15}",

_name, _contactPhone );

case "pr":

return string.Format( "{0,15}, {1,10:C}",

_contactPhone, _revenue );

case "pn":

return string.Format( "{0,15}, {1,20}",

_contactPhone, _name );

case "rn":

return string.Format( "{0,10:C}, {1,20}",

_revenue, _name );

case "rp":

return string.Format( "{0,10:C}, {1,20}",

_revenue, _contactPhone );

case "nrp":

return string.Format( "{0,20}, {1,10:C}, {2,15}",

_name, _revenue, _contactPhone );

case "npr":

return string.Format( "{0,20}, {1,15}, {2,10:C}",

_name, _contactPhone, _revenue );

case "pnr":

return string.Format( "{0,15}, {1,20}, {2,10:C}",

_contactPhone, _name, _revenue );

case "prn":

return string.Format( "{0,15}, {1,10:C}, {2,15}",

_contactPhone, _revenue, _name );

case "rpn":

return string.Format( "{0,10:C}, {1,15}, {2,20}",

_revenue, _contactPhone, _name );

case "rnp":

return string.Format( "{0,10:C}, {1,20}, {2,15}",

_revenue, _name, _contactPhone );

case "n":

case "G":

default:

return _name;

}

}

#endregion

添加该函数使得Customer类型的客户可以定制Customer类型的表示：

IFormattable c1 = new Customer();

Console.WriteLine( "Customer record: {0}",

c1.ToString( "nrp", null ) );

IFormattable.ToString()的实现一般来说是依类型而异的，但有些工作是每一个类型中我们都需要处理的。首先，我们必须支持表示“通用格式”的"G"。其次，我们必须支持两种形式的“空格式”，即""和null。这三种格式返回的字符串必须与Object.ToString()的重写版本返回的字符串相同。.NET FCL对每一个实现了IFormattable接口的类型，会调用IFormattable.ToString()，而非Object.ToString()。.NET FCL通常会用一个null的格式字符串来调用IFormattable.ToString()，只是在一小部分场合会使用"G"来表示通用格式。如果我们的类型支持IFormattable接口，但又不支持这些标准格式，那么我们就打破了FCL中的自动字符串转换规则。

IFormattable.ToString()方法的第二个参数为一个实现了IFormatProvider接口的对象。该对象允许客户程序提供一些我们不能预料的格式化选项。如果看前面IFormattable.ToString()的实现，总会有一些我们期望、但实际上却没有提供的格式化选项。如果我们希望提供的输出容易为人所读懂，这种情况便不可避免。不管我们支持多少种格式化选项，用户总有一天会期望某种我们无法预料的格式。这就是上面的代码示例中最开始的几行所做的工作：寻找实现了IFormatProvider接口的对象，然后将格式化任务交给其中的ICustomFormatter来完成。

下面，将我们的视角从类的作者转到类的使用者上来。假设我们期望的某种格式没有获得支持，例如某些customer的name字符数要大于20，这时候我们希望提供字符数为50的name。这就是IFormatProvider接口的用武之地了。我们需要创建两个类：一个实现IFormatProvider接口，另一个实现ICustomFormatter接口——该类用于创建自定义的输出格式。IFormatProvider接口中定义有一个方法：GetFormat()，该方法会返回一个实现了ICustomFormatter接口的对象。ICustomFormatter接口中包含了实际执行格式化的方法。下面的代码实现了提供字符数为50的name输出：

// IFormatProvider示例：

public class CustomFormatter : IFormatProvider

{

#region IFormatProvider Members

// IFormatProvider 仅包含一个方法。

// 该方法返回一个使用指定接口格式的对象。

// 一般情况下，只有ICustomFormatter被实现。

public object GetFormat( Type formatType )

{

if ( formatType == typeof( ICustomFormatter ))

return new CustomerFormatProvider( );

return null;

}

#endregion

// 一个嵌套类，为Customer类提供定制格式。

private class CustomerFormatProvider : ICustomFormatter

{

#region ICustomFormatter Members

public string Format( string format, object arg,

IFormatProvider formatProvider )

{

Customer c = arg as Customer;

if ( c == null )

return arg.ToString( );

return string.Format( "{0,50}, {1,15}, {2,10:C}",

c.Name, c.ContactPhone, c.Revenue );

}

#endregion

}

}

上面的GetFormat()方法创建了一个实现了ICustomFormatter接口的对象。ICustomFormatter.Format()方法则按指定的方式执行实际的格式化输出工作，将对象转换为一个字符串格式。我们可以为ICustomFormatter.Format()方法定义format参数，以便指定多种格式化选项。参数formatProvider则是用于调用GetFormat()方法的一个IFormatProvider对象。

要指定我们自己定制的格式，需要显式调用string.Format()方法，并传递一个IFormatProvider对象：

Console.WriteLine( string.Format( new CustomFormatter(),

"", c1 ));

不管一个类是否实现了IFormattable接口，我们都可以为其创建IformatProvider和ICustomFormatter的实现类。因此即使一个类的原作者没有提供合理的ToString()行为，我们仍然可以为其提供格式化支持。当然，作为一个类的外部访问者，我们只能通过访问其中的公有属性和数据成员来构造字符串。虽然编写两个类（分别实现IFormatProvider和ICustomFormatter）需要很多工作，且其目的仅仅是为了得到一个字符串。但是，一旦使用了这种方式来实现我们自己定义的字符串输出，它们将在.NET框架的各个地方得到支持。

现在，再让我们回到类作者这一角色上来。重写Object.ToString()是为类提供字符串表示的最简单方式。每当我们创建一个类型时，都要提供该方法。它应该是我们的类型最明显、最常用的一种表示。只有在一些比较少的情况下，当我们期望为类型提供更复杂的输出格式时，才应该实现IFormattable接口。它为“类型的用户定制类型的字符串输出”提供了一种标准的方式。如果我们没有做这些工作，用户就要自己来实现自定义格式化器。那样的做法需要更多的代码，因为用户处于类外，无法访问对象的内部状态。

人们总有获取类型信息的需求，而字符串对于人来说是最容易理解的。我们应该积极地去做这件事，而重写所有类型中的ToString()方法可能是所有做法中用最简单的。