-
简单明确
单个单词简单明确
约束规则:在创建方法时,需要遵守一定的规则,方便调用者理解,相互关联的方法可以考虑保留一致的前缀或后缀//例: size(); remove(); removeAll() //反例: countObservers(); deleteObserver(Observer); deleteObservers();
//例: execute(String); executeBatch(); executeQuery(String); executeUpdate(String);
-
限制长度
不要超过4个单词,这样会大大降低可读性,虽然作用显得更明确,但是太过啰嗦
反例:AbstractBeanFactoryBasedTargetSourceCreator -
参数限制
方法里有过多参数往往让人不能明确区分其作用,特别在重载方法时,多个方法参数五花八门,会让人不知所措,可以考虑重新优化代码结构或者重新定义一个model
反例:regionMatches(boolean, int, String, int, int)
在遇到多个参数的情况下,需要遵守一定原则:数组在前(如:copyOf(T[], int)) -
返回参数
单个对象没有找到返回null或者抛出异常由调用者来处理;
列表不能返回null,如何没有需要返回的数据就返回一个空集合,防止调用处未能进行空处理而导致异常的发生。 -
命名格式
(1)回调(onSomethingDone) :由其他类来调用本类中的方法,在Listener和Callback中是比较常见的
例:onTitleChanged
(2)主动调用(doSomething):一般是比较常见的方法,多数由本类中其他方法来调用,但是许多开发者利用或创建时却很随意,可用在优化代码显示,比价常见的命名有:reset,refresh,init
例:invalidateOptionsMenu
总结
API的设计过程很多时候不能一撮而就,需要慢慢积累和进化,一个功能性的API一旦设计出来,意味着在一定时间内是相对稳定的,使用者能够放心的去调用,所以也需要一定的前瞻性,特别是对于Android开发着来说,其系统版本的高速迭代,可能会或多或少的影响到自己设计的程序;每个API接口应该只专注一件事,并做好(如果它很难命名,那么这或许是个不好的征兆,好的名称可以驱动开发、并且只需拆分与合并模块即可);遵守最小惊讶原则,用户API只需根据需求来设计即可,不需要刻意去设计一下复杂无用的API。
Thanks
http://www.csdn.net/article/2013-04-10/2814835-how-design-good-regular-api
http://blog.csdn.net/hdy007/article/details/1508834
http://www.codeceo.com/article/google-java-good-api.html
网友评论