-
简单明确
单个单词简单明确
约束规则：在创建方法时，需要遵守一定的规则，方便调用者理解，相互关联的方法可以考虑保留一致的前缀或后缀//例： 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
