《NET 设计规范》第 2 章 框架设计基础

　　要设计功能强大又易于使用的框架。

　　要理解广大开发人员并有针对性地为他们设计框架。

　　要理解各种编程语言，并为他们设计框架。　　

2.1 渐进框架

2.2 框架设计的基本原则

　　要确保在设计任何包含公用API的特性时，把 API 设计规格书作为它最核心的部分。

　　要为每个主要的特性域定义一些最常见的使用场景。

　　要确保使用场景与适当的抽象层次相对应。场景应该大致与最终用户的用例相对应。

　　要在设计 API 时，先为主要的使用场景编写样例代码，然后在定义对象模型来支持这些样例代码。

　　要用至少两种不同风格的编程语言来为主要场景编写样例代码。

　　考虑用动态类型语言来为主要场景编写样例代码。

　　不要在设计框架的公用 API 时完全依赖于标准的设计方法。

　　要安排可用性测试研究来测试用于主要场景的 API。

　　要确保每个主要特性域的命名空间只包含那些用于最常见场景的类型。应该把用于更高级场景的类型放在子命名空间中。

　　要为构造函数和方法提供简单的重载函数。一个简单的重载函数不仅参数的数量非常少，而且所有的参数都是基本类型。

　　不要把用于高级场景的成员放在为主要使用场景而设计的类型中。

　　不要要求用于在最基本的场景中显示地实例化一个以上的类型。

　　不要要求用户在为基本使用场景编写代码之前就进行大量的初始化。

　　要尽可能地（用便利的重载函数）为所有的属性和参数提供合适的默认值。

　　要通过异常来传达对 API 的误用。

　　要确保 API 是直观的，无需查阅参考文档就能用于基本场景。

　　要为所有的 API 提供优秀的文档。

　　要在审查规格书的时候投入大量的时间和精力，来讨论标识符名称的选择。

　　不要担心标识符的名字太冗长。

　　考虑在设计过程的早期让用于教育专家参与。考虑把最好的名字留给常用类型。

　　要通过异常消息来告诉开发人员对框架的误用。

　　要尽可能地提供强类型的 API。

　　要确保与 .NET 框架以及客户可能会使用的其它框架保持一致。

　　避免在主要场景的 API 中使用太多的抽象。

　　考虑对框架进行分层，使高层API能够提供最佳的开发效率，低层API能提供最强大的功能和最丰富的表现力。

　　避免把非常复杂（即包含许多类型）的低层API和高层API混在同一个命名空间中。

　　要确保单个特性域中不同的层能很好地集成在一起。开发人员应该能在开始时使用其中一层来进行开发，然后通过修改代码就可以使用另一层，而且这样的改动应该无需重写整个应用程序。