由于我怕文章的篇幅过长会使人看了头痛，所以，我打算分几篇文章把《.NET设计规范》第二章的学习笔记写出来，这样大家看着不至于太累！大概是接下去总共五篇文章是说“框架设计基础”的......

对用户而言，真正的开发效率来自能够轻易地创造出非凡的产品，而并非来自能够轻易地创造垃圾。

场景驱动设计的原则

框架通常包含非常大的一组API。但在开发过程中，真正用到的只是其中较小的一个子集，只会涉及一小部分常用场景。

在设计框架时，使用场景来驱动。从用户的角度，先自己编写一些对主要场景来说必不可少的代码，然后再设计对象模型（object model）来支持这些样例代码。

于功能性规范之前，先撰写一份场景驱动的API规范，应该列出一个给定的技术领域中最常用的5—10个使用场景，并列出实现这些场景的样例代码，至少用两种语言编写。

• 要确保对任何包含公用API的特性设计来说，其核心部分都是API设计规范。
• 要为每个主要的特性域（feature area）定义一些最常用的场景。
• 要确保使用场景与适当的抽象层次相对应。场景应该大致与最终用户的用例相对应。
• 先为主要的使用场景编写样例代码，然后再定义对象模型来支持这些样例代码。
• 要用至少两种不同的编程语言来为主要场景编写样例代码。
  最好能保证所选编程语言的语法和风格差异很大。
• 不要在设计框架的公用API时完全依赖于标准的设计方法。
  标准的设计方法（包括面向对象的方法）是为了使设计的具体实现容易维护，而不是为了使得到的API易于使用。
  以场景驱动设计为主，辅以原型制作、可用性研究以及一定数量的迭代，这种方法要比标准的设计方法好得多。
  可用性研究是为了确定开发人员真正的需求。这跟需求获取一样，设计师此时化身为一名需求分析师，而开发人员则变成了客户。需求分析师不能想当然的认为客户的真正需求是什么，一定要通过跟客户交流才行，站在客户的角度考虑问题。跟需求获取类似，可用性研究宜早不宜迟。
• 要安排可用性研究来测试用于主要场景的API。
  如果开发人员在为主要场景编写代码时，遇到较大问题，则说明API需要重新设计。在原有API的基础上修改，开销反而大，而且是很大。

待续....