应用编程接口（API）的设计制造技术

用于设计应用编程接口（ＡＰＩ）的第一示例性方法实现包括：为核心场景准备多个代码样本，该多个代码样本的每一相应的代码样本对应于多个编程语言的一相应的编程语言；以及响应于该多个代码样本，从该核心场景衍生ＡＰＩ。用于设计ＡＰＩ的第二示例性方法包括：为特征区域选择核心场景；为该核心场景书写至少一个代码样本；以及响应于该至少一个代码样本衍生用于该核心场景的ＡＰＩ。用于设计ＡＰＩ的第三示例性方法包括：响应于对核心场景书写的至少一个代码样本衍生用于该核心场景的ＡＰＩ；使用多个开发者在该ＡＰＩ上执行一个或多个可用性学习；以及基于该一个或多个可用性学习修订该ＡＰＩ。

【技术实现步骤摘要】

本专利技术一般涉及应用编程接口(API)，尤其涉及，作为示例而非局限，设计易于使用的API而同时提供控制和灵活性。
技术介绍
应用编程接口(API)由开发者用于创建各种各样的应用和程序。开发者的范围从记录宏的办公室工作人员到低层设备驱动器作者。这些开发者依靠具有不同复杂度的不同语言和/或不同框架，而使用不同的技能组和/或为不同的目的来编程。传统地，设计了不同的API以不同的个别技能级别和对控制的不同需求(如基于不同的相关场景)为目标。尽管该方法能够成功地提供为具体的开发者优化的API，它仍具有显著的不足。例如，多框架方法产生了开发者很难将知识从一个技能级别和场景类型转移到另一个的情况。当他们需要使用不同的框架实现场景时，开发者遭遇陡峭的(steep)学习曲线。并且不仅学习曲线极陡峭，而且它一般需要写入第一较低技能级别框架的代码必须被从无到有地写入第二较低技能级别框架中。此外，为不同的开发者技能级别创建单独的框架通常导致以一个级别开发者为目标或由其实现的API无法由另一级别开发者使用的情况。图1示出了关于两种不同框架的传统API学习曲线的曲线图101。第一框架对应于具有相对较低级别的技能和/或难度要求同时伴之以由开发者控制的容量相对较低的框架。另一方面，第二框架对应于具有相对较高级别的所需要的技能和/或难度以及伴随的用于由开发者控制的相对较高容量的框架。这样的第一框架可由新手或偶尔为之的开发者使用，并且这样的第二框架可由有经验的或专业开发者使用。例如，第一框架可对应于为Visual Basic所设计的框架，而第二框架可对应于为C++所设计的框架。在该传统方法中，设计并采用了相对分离且全异的API作为每一框架的一部分。跨越陡峭但相对较短的学习曲线来启用为相对较低技能级别和控制能力的第一框架的API使用。由于两个API框架的分离和全异特性，对第一框架的经验对于学习第二框架的第二API所贡献的知识很少，如果说有的话。因此，要跨越同样陡峭、甚至更高的学习曲线来启动第二框架的API的使用。换言之，学习第一框架的API不能提供学习第二框架的API的垫脚石。这一脱节的API框架组的退步特性由连续性间隙指示。学习了第一框架的API的开发者并不能更便捷地学习第二框架的API，并且因此必须从第二框架的基础开始。传统框架的另一问题是它们往往在任一情况下都具有总体较差的可用性。一般而言，“优化”面向对象设计/开发(OOD)方法(如，统一模型化语言(UML))是为了所得设计的可维护性，而不是所得框架的可用性。OOD方法更适合内部结构设计，但较不适合大型可重复使用库的API层的设计。例如，较差的可用性可根源于OOD方法仅关注在对较低功能块的提炼和/或贯穿整个API设计对严格的继承层次具有不动摇的忠诚度。因此，需要能够至少改进传统API学习曲线的倒退连续性间隙和/或能够供应较好的整体API可用性的模式和/或技术。
技术实现思路
在第一示例性方法实现中，用于设计应用编程接口(API)的方法包括为核心场景准备多个代码样本，多个代码样本的每一相应的代码样本对应于多个编程语言的相应的编程语言；以及响应于多个代码样本从核心场景衍生API。在第二示例性方法实现中，用于设计API的方法包括为一特征区域选择核心场景；为该核心场景书写至少一个代码样本；以及响应于至少一个代码样本为核心场景衍生API。在第三示例性方法实现中，用于设计API的方法包括响应于相对一场景书写的至少一个代码样本，为该场景衍生API；使用多个开发者在该API上执行一个或多个可用学习；以及基于该一个或多个可用学习修正该API。本专利技术描述了其它方法、系统、途径、装置、设备、媒体、API、过程、排列等实现。附图说明贯穿附图，使用相同的标号标识相同和/或对应的方面、特征和组件。图1示出了关于两个不同框架的传统API学习曲线的曲线图。图2示出了关于两个级别的抽象的示例性有渐进API学习曲线的曲线图。图3示出了API的示例性设计原理和实践。图4所示是用于每特征区域设计API的示例性技术的流程图。图5所示是用于每核心场景设计API的示例性模式的框图。图6示出了以两个不同的目的为目标的示例性组件类型之间的潜在不一致性。图7示出了被设计成可扩充和/或能共同操作以覆盖两个不同目的的组件类型之间的示例性关系。图8示出了用于处理两层API的两个不同目的的示例性聚集组件(AC)和关联的分解类型(FT)。图9示出了支持创建—设置—调用用法模式的示例性聚集组件和关联的API。图10示出了能够(全部或部分地)实现设计和/或使用本专利技术描述的API的至少一个方面的示例性计算(或一般设备)操作环境。具体实施例方式图2示出了关于两个不同的抽象级别的示例性渐进API学习曲线的曲线图200。所示的两个不同级别的抽象一个是相对高度抽象，一个是相对低度抽象。该高度抽象对应于其涉及所需技能和/或难度级别相对较低、且伴之以由开发者控制的容量相对较低的开发环境。另一方面，低度抽象对应于其涉及所需技能和/或难度级别相对较高、且伴之以由开发者控制的容量相对较高的开发环境。示出渐进API学习曲线以相对平滑的方式从较低的需要技能和伴随的控制能力的一点处升起，通过高级和低度抽象的区域，到较高的需要技能和伴随的控制能力的一点。渐进API学习曲线呈现出高度抽象和低度抽象之间的连续区。一种集成的API框架可启用渐进的学习曲线。由于该API框架的集成特性，对高度抽象的经验向低度抽象以及需要更大控制的场景进行的API使用学习贡献了知识。换言之，学习用于高度抽象的API向学习API和/或将API扩充到低度抽象中提供了垫脚石。这由包含高度和低度抽象区域的两层API框架形状指示。如后文所描述的，某些API的渐进特性令开发者能够最初使用简单的API，然后渐进地(并部分地)开始使用更复杂的API组件。由此，学习了以高度抽象为目标的API的开发者能够在其经验提供了某种保证和/或当他们所面对的场景的复杂度提出需要时转而使用以低度抽象为目标的API。渐进API可以是易于使用(尤其在早期学习阶段)并且高度功能强大的(尤其是当随时间推移研究API时)。可使用的API可包括以下示例性属性的一个或多个起步时需要少量概念和/或类、几行代码可实现简单的场景、类/方法具有直观的名字、自然的和/或明显的起点是显而易见的、并且有到另外需要的和/或相关的概念/类的清楚的(如可发现的)渐进。渐进API也可启用从在较低难度和伴随的控制能力的一点处发展到较高难度和伴随的控制能力的一点的递增前进。下文描述了用于设计渐进API以及一般高度可使用的API的示例性范例。图3在表300中示出了API的示例性设计原理和实践。表300指示四个示例性类别302-308的一般设计原理和实践。具体地，着眼于以下四个类别场景驱动设计302、面向组件设计304、可定制默认值306和自编对象模型308。当设计给定的API时，可采用用于指示的类别302-308的任一一个或多个的设计原理和实践。此外，在任一给定的类别302-308内，可实现所示的设计原理和实践的一个或多个。换言之，不需要为给定的API设计采用或实现每一类别或每一设计原理和实践。场景驱动设计类别302示出了四个示例性设计原理和实践。首先，定义了所选本文档来自技高网...

【技术保护点】
一种设计应用编程接口（ＡＰＩ）的方法，其特征在于，所述方法包括：为核心场景准备多个代码样本，所述多个代码样本的每一相应的代码样本对应于多个编程语言的一相应的编程语言；以及响应于所述多个代码样本，从所述核心场景衍生所述ＡＰＩ。

【技术特征摘要】
US 2003-10-23 10/692,3201.一种设计应用编程接口(API)的方法，其特征在于，所述方法包括为核心场景准备多个代码样本，所述多个代码样本的每一相应的代码样本对应于多个编程语言的一相应的编程语言；以及响应于所述多个代码样本，从所述核心场景衍生所述API。2.如权利要求1所述的方法，其特征在于，它还包括由API设计者确定所衍生的API是否太过复杂。3.如权利要求2所述的方法，其特征在于，它还包括如果所衍生的API被确定为太过复杂，则由所述API设计者提炼所衍生的API以生成提炼的API。4.如权利要求3所述的方法，其特征在于，它还包括由所述API设计者确定所提炼的API是否太过复杂。5.如权利要求1所述的方法，其特征在于，它还包括使用多个开发者在所述API上执行一个或多个可用性学习。6.如权利要求5所述的方法，其特征在于，所述执行包括使用所述多个开发者在所述API上执行所述一个或多个可用性学习，其中，所述多个开发者对所述多个编程语言是典型的。7.如权利要求5所述的方法，其特征在于，它还包括断定所述多个开发者是否能够在没有重大问题的情况下使用所述API。8.如权利要求7所述的方法，其特征在于，它还包括如果所述多个开发者不被断定为能够在没有重大问题的情况下使用所述API，则修订所述API。9.如权利要求8所述的方法，其特征在于，所述修订包括基于来自所述一个或多个可用性学习的至少一个经验修订所述API。10.如权利要求1所述的方法，其特征在于，所述衍生包括衍生所述API以支持分别对应于所述多个编程语言的所述多个代码样本。11.如权利要求1所述的方法，其特征在于，所述衍生包括从所述多个代码样本收集语言专用命令；以及将所述语言专用命令结合进所述API中。12.如权利要求1所述的方法，其特征在于，所述衍生包括从所述多个代码样本收集语言启示的开发者期望；以及将所述语言启发的开发者期望结合进所述API中。13.如权利要求1所述的方法，其特征在于，所述衍生包括从所述多个代码样本收集通用性；以及将所述通用性结合进所述API中。14.如权利要求1所述的方法，其特征在于，所述衍生包括衍生所述API以具有将多个低层分解类型捆绑在一起以支持所述核心场景的聚集组件。15.一种设计应用编程接口(API)的方法，其特征在于，所述方法包括为特征区域选择核心场景；为所述核心场景书写至少一个代码样本；以及响应于所述至少一个代码样本，衍生用于所述核心场景的API。16.如权利要求15所述的方法，其特征在于，所述选择包括为所述特征区域选择多个核心场景。17.如权利要求16所述的方法，其特征在于，它还包括对为所述特征区域所选择的多个核心场景的每一核心场景重复所述书写和所述衍生。18.如权利要求15所述的方法，其特征在于，所述书写包括为所述核心场景书写多个代码样本，所述多个代码样本的每一相应的代码样本对应于多个编程语言的一相应的编程语言。19.如权利要求18所述的方法，其特征在于，所述衍生包括响应于所述多个代码样本衍生用于所述核心场景的API。20.如权利要求15所述的方法，其特征在于，它还包括使用多个开发者在所述API上执行一个或多个可用性学习；断定所述多个开发者是否能够在没有重大问题的情况下使用所述API；以及如果所述多个开发者不被断定为能够在没有重大问题的情况下使用所述API，则修订所述API。21.如权利要求20所述的方法，其特征在于，所述修订包括基于来自所述一个或多个可用性学习的至少一个经验修订所述API以生成修订的API。22.如权利要求21所述的方法，其特征在于，它还包括对所述修订的API重复所述执行和所述断定。23.如权利要求15所述的方法，其特征在于，所述衍生包括通过生成一包括一聚集组件和多个基础分解类型的双层API，衍生所述API以支持为所述核心场景书写的至少一个代码样本。24.如权利要求15所述的方法，其特征在于，所述衍生包括从所述至少一个代码样本收集一个或多个语言专用命令；以及将所述一个或多个语言专用命令结合进所述API中。25.如权利要求15所述的方法，其特征在于，所述衍生包括如果一特定的分解类型的所有成员由与所述核心场景关联的聚集组件展现，将所述特定的分解类型封装到所述聚集组件中。26.如权利要求15所述的方法，其特征在于，所述衍生包括如果一特定的分解类型对其它组件类型是独立地不感兴趣的，则将所述特定的分解类型封装到与所述核心场景关联的聚集组件中。27.如权利要求15所述的方法，其特征在于，所述衍生包括如果一特定类型的至少一个成员不由与所述核心场景关联的聚集组件展现，则从所述聚集组件展现所述特定的分解类型。28.如权利要求15所述的方法，其特征在于，所述衍生包括如果一特定的分解类型可以由另一组件类型独立于与所述核心场景关联的聚集组件有利使用，则从所述聚集组件展现所述特定的分解类型。29.如权利要求15所述的方法，其特征在于，所述衍生包括生成一包括以相对高度抽象为目标的组件类型和以相对低度抽象为目标的组件类型的双层框架。30.如权利要求29所述的方法，其特征在于，以相对高度抽象为目标的所述组件类型被定向到核心场景。31.如权利要求29所述的方法，其特征在于，以相对低度抽象为目标的所述组件类型与以相对高度抽象为目标的所述组件类型相比，向开发者提供了相对更大数量的控制。32.如权利要求15所述的方法，其特征在于，所述衍生包括衍生所述API以令开发者能够为所述核心场景实现一创建-设置-调用用法模式。33.如权利要求32所述的方法，其特征在于，所述衍生包括用预选择的适合所述核心场景的参数产生所述API。34.一种设计应用编程接口(API)的方法，其特征在于，它包括响应于对场景书写的至少一个代码样本，衍生用于所述场景的API；使用多个开发者在所述API上执行一个或多个可用性...

【专利技术属性】
技术研发人员：AJ摩尔，BM阿布拉姆斯，CL安德森，KJ克瓦里纳，MJ皮佐，RA布里罕姆，
申请(专利权)人：微软公司，
类型：发明
国别省市：US[美国]