但是我们为什么还要修正API呢?为了API看起来更加俊秀?为了供应更多功能?为了供应更好的性能?还是仅仅以为到了改变了时候了?对付用户来说,他们更乐意利用一个稳定但是看起来不那么时髦的API,这并不虞味着我们不再改进API了。当糟糕的API带来的掩护本钱越来越大时,我想便是我们去重构它的时候。
如果可以转头重新再做一遍,那么我心目中的精良的API该当是怎么样的?
判断一个API是否精良,并不是大略地根据第一个版本给出判断的,而是要看随着韶光的推移,该API是否还能存在,是否仍旧保持得不错。槽糕的API接口各种各样,但是好的API接口对付用户来说必须知足以下几个点:
易学习:有完善的文档及供应尽可能多的示例和可copy-paste的代码,像其他设计事情一样,你该当运用最小惊异原则。易利用:没有繁芜的程序、繁芜的细节,易于学习;灵巧的API许可按字段排序、可自定义分页、 排序和筛选等。一个完全的API意味着被期望的功能都包含在内。难误用:对详细的缺点提示,有些履历的用户可以直策应用API而不须要阅读文档。
而对付开拓职员来说,哀求又是不一样的:
易阅读:代码的编写只须要一次一次,但是当调试或者修正的时候都须要对代码进行阅读。易开拓:个最小化的接口是利用尽可能少的类以及尽可能少的类成员。这样使得理解、影象、调试以及改变API更随意马虎。如何做到以上几点,以下是一些总结:
1、 面向用例设计
如果一个API被广泛利用了,那么就不可能理解所有利用该API的用户。如果设计者希望能够设计出被广泛利用的API,那么必须站在用户的角度来理解如何设计API库,以及如何才能设计出这样的API库。
2、 采取良好的设计思路
在设计过程中,如果能按照下面的办法来进行设计,会让这个API生命更长久
面向用例的设计,网络用户建议,把自己仿照成用户,担保API设计的易用和合理担保后续的需求可以通过扩展的形式完成初版做只管即便少的内容,由于新需求可以通过扩展的形式完成,因此只管即便少干工作是抑制API设计缺点的一个有效方案对外供应清晰的API和文档规范,避免用户缺点的利用API,尤其是避免API(见第一节)靠后级别的API被用户知晓与误用除此之外,下面还列出了一些详细的设计方法:
方法优于属性工厂方法优于布局函数避免过多继续避免由于优化或者复用代码影响API面向接口编程扩展参数应该是便利的对组件进行合理定位,确定暴露多少接供词给扩展点3、 避免极度的见地
在设计API的时候,一定要避免任何极度的见地,尤其因此下几点:
必须俊秀(API不一定须要俊秀)API必须被精确地利用(用户很难明得如何精确的利用API,API的设计者要充分考虑API被误用的情形:如果一个API可能会被误用,那么它一定会被误用)必须大略(我们总会面临繁芜的需求,能两者兼顾的API是更好的API)必须高性能(性能可以通过其他手段优化,不应该影响API的设计)必须绝对兼容(只管本文一贯提到如何担保兼容,但是我们仍旧要意识到,一些极少情形下会碰着的不兼容是可以容忍的)4、 有效的API评审
API设计完成往后,须要经由周密的设计评审,评审的重点如下:
用例驱动,评审前必须供应完善的利用用例,确保用例的合理性和完备性。同等性,是否与系统中其他模块的接口风格同等,是否与对称接口的设计同等。大略明了,API该当大略好理解,随意马虎学习和利用的API才不随意马虎被误用,给我们带来更多的麻烦。API尽可能少,如果一个API可以暴露也可以不暴露,那么就不要暴露他,等到用户真正有需求的时候再将它成为一个公开接口也不迟。支持持续改进,API是否能够方便地通过扩展的办法增加功能和优化。5、 提高API的可测试性
API须要是可测试的,测试不应依赖实现,测试充分的API,尤其是经由了严格的“兼容性整合测试”的API,更能担保在升级的过程中不涌现兼容性问题。兼容性整合测试,是指一组测试用例凑集,这组测试用例会站在利用者的态度上利用API。在API升级往后,再检测这组测试用例是否能完备符合预期的通过测试,尽可能的创造兼容性问题。
6、 担保API的向后兼容
对付每一个API的设计者来说,都渴望做到“向后兼容”,由于不管是现在的API用户,还是潜在的API用户,都只信赖那些可兼容的API。但向后兼容有多个层次上的意义,而且不同层次的向后兼容,也意味着不同的主要性和繁芜度。
7、 保持逐步改进
过去我们总希望能将现有的“不合理”的设计完备推翻,然后按照现在“美好”的思路,重新设计这个API,但是在一段韶光往后,又会碰到一样的状况,须要再推翻一次。 如果我们没有有效的逐步改进的办法,依赖推翻现有设计,重新设计API只能让我们回到出发点,然后重现之前的过程。 要有一套行之有效的持续改进的办法来在API兼容的同时,改进API使之更好。
8、 把握API的生命周期
每一个API都是有生命周期的,我们须要让API的生命周期更长,并且在API的生命周期结束时能让其平滑的消亡。
见告用户我们是如何设计的,避免误用,供应辅导,缺点的利用每每是缩短API寿命的一大杀手供应试用期,API不可能一开始便是稳定,经由试用的API才能有更强的生命力为API分级:内部利用;二次开拓利用;开拓或试用中;稳定;弃用API。避免API被滥用的同时,我们可以通过调度API的级别,来扩大其影响力,也能更优雅的结束一个API的生命周期。开拓API的过程实在便是一个沟通互换的过程。沟通的双方便是API用户和API设计者。
9、 一些详细的履行方案
在一个API不可避免要消亡或者改变的时候,我们该当接管并且面对这个事实,下面列举了几种担保兼容性的条件下,对API进行调度的办法:
将API标记为弃用,重新建立一个新的API。如果一个API不可避免要被消亡,这是唯一的办法。为其添加额外的参数或者参数选项来实现功能添加将现有API拆成两部分,供应一个精简的核心API,过去的API通过封装核心API上实现。这常日用于办理用户须要一个代码精简的版本时。在现有的API根本上进行封装,供应一个功能更丰富的包或者类一些好的API示例:
Flickr API,这里是文档的示例,同时供应了一个非常方便的API测试工具。Mediawiki APIEbay API,这里有一个非常详尽的文档示例。转载地址:http://www.apkbus.com/blog-822715-68552.html