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