• 考虑对框架进行分层，使高层API能提供最佳的开发效率，低层API能提供最强大的功能和最丰富的表现力。
  通俗地讲，象我这样的菜鸟只能用高层API，太低层都不懂，而牛人们都是想用也更愿意用低层API的强大功能的（个人意见）。ps：这边的高层跟低层不是指高深的意思。而是从易用性方面考虑的！
• 避免把低层API和高层API混在同一名字空间中，如果低层API非常复杂的话（即包含了许多类型）。
• 要确保单个特性域中不同的层能很好的集成在一起。

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

场景驱动设计的原则

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

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

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

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