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

 

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

场景驱动设计的原则

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

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

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

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

待续....