Android的API设计

1. 简单明确
   单个单词简单明确

   //例：
    size();
    remove();
    removeAll()
   
   //反例：
    countObservers();
    deleteObserver(Observer);
    deleteObservers();
   

   约束规则：在创建方法时，需要遵守一定的规则，方便调用者理解，相互关联的方法可以考虑保留一致的前缀或后缀

   //例：
    execute(String);
    executeBatch();
    executeQuery(String);
    executeUpdate(String);
   

2. 限制长度
   不要超过4个单词，这样会大大降低可读性，虽然作用显得更明确，但是太过啰嗦
   反例:AbstractBeanFactoryBasedTargetSourceCreator
3. 参数限制
   方法里有过多参数往往让人不能明确区分其作用，特别在重载方法时，多个方法参数五花八门，会让人不知所措，可以考虑重新优化代码结构或者重新定义一个model
   反例：regionMatches(boolean, int, String, int, int)
   在遇到多个参数的情况下，需要遵守一定原则：数组在前(如：copyOf(T[], int))
4. 返回参数
   单个对象没有找到返回null或者抛出异常由调用者来处理；
   列表不能返回null,如何没有需要返回的数据就返回一个空集合，防止调用处未能进行空处理而导致异常的发生。
5. 命名格式
   （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