Loading......

    本书介绍了设计框架的最佳实践。所谓框架，即可重用面向对象程序库。书中所描述的规范普遍适用于下述规模不同、可重用程度不同的框架。
    大规模的系统框架。这些框架通常都有成千上万个类型，并且为大量的开发人员所使用，如.NET Framework。. 中等规模的程序库。这既可以是大型分布式应用程序的可重用层，也可以是对系统框架的可重用扩展，如Web服务扩展（Web Services Enhance- ments）。
    小规模组件。为多个应用程序所共享，如网格控件（grid control）库。
    值得注意的是，本书关注的是直接影响框架（可以公开访问的API）可编程能力的设计问题。因此，我们不会过多涉及实现细节。正如一本介绍用户界面设计的书不会讨论有关如何实现碰撞测试（hit testing）的细节一样，本书也不会讲解如何实现二叉排序。这样的定位使我们能够提供针对框架设计师的完整可靠的指南，而不是又一本关于编程方面的书。
    书中的规范是在.NET Framework的开发早期形成的，它们最早只是少量的命名和设计约定，但是经过不断改进、检验、提炼，这些规范最终成为了微软内部公认的框架设计规范。这些规范历经.NET Framework三个版本的长期开发，凝聚了数千名开发人员累积的经验和智慧。我们并不希望本书只是基于一些理想化的设计理念，我们认为本书是极其注重实效的，微软的各开发组将之用于日常开发就是很好的证明。
    本书包含许多评注，它们有的解释了相应规范的利弊权衡，有的介绍了其历史，有的给出了进一步的说明，有的提出了自己的批评意见。所有评注都来自经验丰富的框架设计师、业界专家及用户。这些源于开发一线的故事，为书中的许多规范增色不少。
    为了使命名空间名、类、接口、方法、属性及类型能够在正文中一目了然，我们用Consolas字体表示。
    本书的读者应该基本知道如何使用.NET Framework编程，有一些规范要求读者熟悉.NET Framework 3.5版引入的新特性。如果你想找一本介绍Framework编程的书，那么可以参考书后的Suggested Reading List部分，其中有一些非常好的建议。规范的表示方法
    我们通过要（Do）、考虑（Consider）、避免（Avoid）、不要（Do not）这些词把书中的规范组织成一条条简单的建议。每一条规范都描述了一种好的或是不好的做法，并用统一的方式来表示。好的做法，在其前面会用.表示；与此对应，不好的做法则用.表示。每一条规范的措词也会明确表示出这条规范的重要性。例如，“要……”描述的是必须①遵循的规范（下面所有的例子都摘自本书）：
    DO要在命名自定义的attribute类时加上“Attribute”后缀。
    public class ObsoleteAttribute : Attribute { ... }
    另一方面，“考虑……”描述的是在一般情况下应该遵循的规范，但如果完全理解规范背后的道理，并有很好的理由不遵循它时，也不要畏惧打破常规：
    CONSIDER考虑将类型定义为结构，而不要定义为类，如果该类型的实例较小、存活期较短或通常内嵌在其他对象中。
    同样，“不要……”描述的是一些绝对不应该违反的规范：
    DO NOT不要把可变类型的实例赋给只读字段。“避免……”就没有那么绝对，它描述的做法虽然通常并不好，但却存在一些已知的可以违反该规范的情况：
    AVOID避免使用ICollection< T >或ICollection作为参数，如果其目的仅仅只是为了访问Count属性。
    对那些更为复杂的规范，我们会另外提供一些背景知识、代码示例及基本原理：
    DO要为值类型实现IEquatable< T >。
    值类型的Object.Equals方法会导致装箱，而且由于使用了反射，因此默认实现的效率不高。IEquatable< T >.Equals能够提供更好的性能，而且它的实现可以避免装箱操作。
    public struct Int32 : IEquatable< Int32 > {
    public bool Equals(Int32 other){ ... }}
语言选择和样例代码
    公共语言运行库（CLR）的目标之一就是支持多种编程语言，这其中既包括微软提供的语言，如C++、VB、C#、F#、Python和Ruby，也包括第三方语言，如Eiffel、COBOL和Fortran等。因此，本书适用于开发和使用现代框架的多种语言。
    为了加强多语言框架设计的概念，我们曾考虑过使用几种不同的编程语言来编写样例代码。但最终我们还是放弃了这种想法，因为使用不同的语言虽然有助于理念的表达，但这样做可能会迫使读者学习好几种新语言，而这并不是本书的目的。
    我们决定使用一种易于为广大开发人员阅读的语言，最终选择了C#，因为C#是一种简单的语言，它源自C语言家族——一个在框架开发方面有着悠久历史的家族（C家族中的其他语言包括C、C++、Java和C#）。
    语言的选择对于许多程序员来说至关重要，对那些不适应C#的读者，我们谨在此表示歉意。
    关于本书
    本书提供了自顶向下的框架设计规范。
    . 第1章简要介绍了本书，讨论了框架设计的理念，这是书中唯一没有规范的一章。
    . 第2章为框架的总体设计提供了基本的原则和规范。
    . 第3章包含了常用设计惯用法以及为命名空间、类型、成员等框架各部分命名的规范。
    . 第4章为类型设计提供了规范。
    . 第5章为类型成员的设计提供了进一步的规范。
    . 第6章讨论了一些对保证框架的扩展性来说至关重要的问题和规范。
    . 第7章为与异常有关的工作提供了规范，及推荐使用的错误报告机制。
    . 第8章为扩展和使用框架中的常用类型提供了规范。
    . 第9章为框架中常用的设计模式提供了规范和示例。
    . 附录A对本书使用的编程约定做了简要的描述。
    . 附录B介绍了FxCop工具。可以用该工具来分析框架的二进制文件，以验证框架是否符合本书所描述的规范。本书的附带光盘中包括了此工具。
    . 附录C是一份API规范样例，这些规范通常是微软公司的框架设计人员在设计API时创建的。
    本书附带光盘还包括了另一份API规范样例和其他有用的资源。
致　　谢
    本书实质上是对数千人智慧结晶的一个汇总，对所有这些人我们深表谢意。
    微软公司的许多人在过去几年中长期努力地工作，是他们提出建议，进行辩论，并最终撰写了书中的许多规范。虽然不可能列出所有的参与者，但在此我们要特别感谢：Chris Anderson、Erik Christensen、Jason Clark、Joe Duffy、Patrick Dussud、Anders Hejlsberg、Jim Miller、Michael Murray、Lance Olson、Eric Gunnerson、Dare Obasanjo、Steve Starck、Kit George、Mike Hillberg、Greg Schecter、Mark Boulter、Asad Jawahar、Justin Van Patten和Mircea Trofin。
    许多人审阅了本书并提供了评注，我们在此同样表示感谢：Mark Alcazar、Chris Anderson、Christopher Brumme、Pablo Castro、Jason Clark、Steven Clarke、Joe Duffy、Patrick Dussud、Mike Fanning、Kit George、Jan Gray、Brian Grunkemeyer、Eric Gunnerson、Phil Haack、Anders Hejlsberg、David Kean、Rico Mariani、Anthony Moore、Vance Morrison、Christophe Nasarre、Dare Obasanjo、Brian Pepin、Jon Pincus、Jeff Prosise、Brent Rector、Jeffrey Richter、Greg Schechter、Chris Sells、Steve Starck、Herb Sutter、Clemens Szyperski、Mircea Trofin和Paul Vick。
    上述同仁对本书做了非常必要的补充增益。他们为正文添加了注解内容，补充了有关历史背景知识，让文风变得风趣生动，这些都十分出彩，令本书增色不少。
    附录B对FxCop的介绍实际上是Sheridan Harrison和David Kean编写的，在此我们对他们表示感谢。
    感谢Martin Heller，他从技术上、精神上给我们以帮助和支持。感谢Pierre Nallet、George Byrkit、Khristof Falk、Paul Besley、Bill Wagner和Peter Winkler，他们提出了中肯而有益的意见。
    特别感谢Susann Ragsdale，是她把诸多不甚连续的想法化为本书。她耐心、极具幽默感，她的创作思路完美无瑕，所有这些使得本书的写作过程变得格外轻松。