前 言 本书介绍了设计框架的最佳实践。所谓框架，即可重用面向对象程序库。书中所描述的规范普遍适用于规模不同、可重用程度不同的框架：  大规模的系统框架。这些框架通常都有成千上万个类型，并且为大量的开发人员所使用，如.NET框架。  中等规模的程序库。这既可以是大型分布式应用程序的可重用层，也可以是对系统框架的可重用扩展，如Web服务扩展（Web Services Enhancements）。  小规模组件。为多个应用程序所共享，如一个grid control（网格控件）库。 值得注意的是本书关注的是直接影响框架（可以公开访问的API）可编程能力的设计问题。正因为如此，我们没有过多地涉及实现细节。正如一本介绍用户界面设计的书不会讨论有关如何实现碰撞测试（hit testing）的细节一样，本书也不会讲解如何实现二叉排序。这样的定位使我们能够提供针对框架设计师的完整可靠的指南，而不是又一本关于编程方面的书。 书中的规范是在.NET框架的开发早期形成的，它们最早只是少量的命名和设计约定，但是经过不断改进、检验、提炼，这些规范最终成为了微软内部公认的框架设计规范。这些规范历经.NET框架三个版本的长期开发，凝聚了数千名开发人员累积的经验和智慧。我们并不希望本书只是基于一些理想化的设计理念，我们认为本书是极其注重实效的，微软的各开发组将之用于日常开发就是很好的证明。 本书包含许多评注，它们有的解释了相应规范的利弊权衡，有的介绍了其历史，有的给出了进一步的说明，有的提出了自己的批评意见。所有评注都来自经验丰富的框架设计师、业界专家及用户，这些源于开发一线的故事，为书中的许多规范增色不少。 为了使名字空间名、类、接口、方法、属性及类型能够在正文中一目了然，我们用Courier字体表示。 本书的读者应该基本知道如何使用.NET框架进行编程，有一些规范要求读者熟悉.NET框架2.0版引入的新特性。如果你想找一本介绍框架设计的书，那么可以参考书后的“推荐读物”，其中有一些非常好的建议。 规范的表示方法 我们通过要、考虑、避免、不要这些词把书中的规范组织成一条条简单的建议。每一条规范都描述了一种好的或是不好的做法，并用统一的方式来表示。对于好的做法，在其前面会用ü表示，与此对应，不好的做法则用û表示。每一条规范的措词也会明确表示出这条规范的重要性。例如，“要……”描述的是必须 遵循的规范（下面所有的例子都摘自本书）：  要在命名自定义的attribute类时加上“Attribute”后缀。 public class ObsoleteAttribute : Attribute { … } 另一方面，“考虑……”描述的是在一般情况下应该遵循的规范，但如果完全理解规范背后的道理，并有很好的理由不遵循它时，也不要畏惧打破常规：  考虑将类型定义为结构，而不要定义为类，如果该类型的实例较小、存活期较短或通常内嵌在其他对象中。 同样，“不要……”描述的是一些几乎绝对不应该违反的规范：  不要把可变类型的实例赋给只读字段。 “避免……”就没有那么绝对，它描述的做法虽然通常并不好，但却存在一些已知的可以违反该规范的情况：  避免使用ICollection或ICollection作为参数，如果其目的仅仅只是为了访问Count属性。 对那些更为复杂的规范，我们会另外提供一些背景知识、代码示例及基本原理：  要为值类型实现IEquatable。 值类型的Object.Equals方法会导致装箱，而且由于使用了反射，因此默认实现的效率不高。IEquatable.Equals能够提供更好的性能，而且它的实现可以避免装箱操作。 public struct Int32 : IEquatable { public bool Equals(Int32 other){ … } } 语言选择和样例代码 公共语言运行库的目标之一就是支持多种编程语言，这其中既包括微软提供的语言，如C++、VB和C#，也包括第三方语言，如Eiffel、COBOL和Python，等等。因此，本书适用于开发和使用现代框架的多种语言。 为了加强多语言框架设计的概念，我们曾考虑过使用几种不同的编程语言来编写样例代码。但最终我们还是放弃了这种想法，这是因为使用不同的语言虽然有助于理念的表达，但这样做可能会迫使读者学习好几种新语言，而这并不是本书的目的。 我们决定使用一种易于为广大开发人员阅读的语言，最终选择了C#，因为C#是一种简单的语言，它源自C语言家族——一个在框架开发方面有着悠久历史的家族（C家族中的其他语言包括C、C++及Java）。 语言的选择对于许多程序员来说至关重要，对那些不适应C#的读者，我们谨在此表示歉意。 关于本书 本书提供了自顶向下的框架设计规范。  第1章简要介绍了本书，讨论了框架设计的理念，这是书中唯一没有规范的一章。  第2章为框架的总体设计提供了基本的原则和规范。  第3章包含了为框架各部分命名的规范，包括名字空间、类型、成员及常用的设计惯用法。  第4章为类型设计提供了规范。  第5章为类型成员的设计提供了进一步的规范。  第6章讨论了一些对保证框架的扩展性来说至关重要的问题和规范。  第7章为与异常有关的工作提供了规范，及推荐使用的错误报告机制。  第8章为扩展和使用框架中的常用类型提供了规范。  第9章为框架中常用的设计模式提供了规范和示例。  附录A对本书使用的编程约定做了简要的描述。  附录B介绍了FxCop工具。可以用该工具来分析框架的二进制文件，以验证框架是否符合本书所描述的规范。本书的配套资源中包括了此工具。  附录C是一份API规范样例，这些规范通常是微软公司的框架设计人员在设计API时创建的。 本书的配套资源 还包括了另一份API规范样例和其他有用的资源。