本文源自Google工程师joshua bloch的经验分享，楼主进行了整理和总结。


一、好接口的特性
（1）易学
（2）易用，甚至不需要文档
（3）难于误用
（4）容易阅读与维护
（5）容易扩展


二、接口设计实现的过程
（1）分析需求
考虑是否有更佳解决方案？
这是否使我们这真想要的需求？
（2）设计小接口
这个阶段，快速敏捷迭代
小接口易于修改
小接口的实现给人自信，减少挫败感
（3）高频、提早撰写接口
实现自测用例
（4）撰写服务提供接口（SPI：service provider interface）尤为重要
如果提供一个接口，是否就不支持第二个？
如果提供两个接口，是否能够扩展，融合？
如果提供三个接口，是否足够？能否工作正常？
（5）注意“正常的”异常维护
你的接口是为了满足所有需求？
即使有异常，也不要紧


三、接口设计的基本原则
（1）只做并做好一件事
函数名自解释；
不恰当的函数名，往往是不恰当设计的征兆
（2）如果没做到（1），就将函数分解
只增加，永远不要删除函数与接口
你永远不知道这个接口被谁在使用
（3）实现永远不能影响接口
举例：不能假定函数调用者只能使用hash
不能对外暴露实现细节
（4）最小化访问
尽量使用私有化成员
注意信息隐藏
（5）文档与注释
接口不是只写给自己（即使只给自己，也应该有说明）
（6）提高性能
（7）平台无关


四、类设计
（1）最小易变性
举例：Date不宜设计成类，过于易变；可设计为TimerTask
如果可变，则要设计良好、最小化的状态子集合
（2）尽量少用继承
如果设计一个类不能被继承，则应该明确禁止


五、方法设计
（1）不要到处拷贝模板代码
模块能做的事，不用到处拷贝方法
（2）原子性应该在一个方法内保证
（3）Fail-Fast设计原则
出错尽量早点返回，交给上层处理，不要勉强抢救
（4）避免数据直接访问，而是提供访问方法
（5）谨慎重载
小心多重继承中的误重载
可以重载的情况，也慎重考虑是否应该重载
（6）注意参数与返回值类型
尽量明确类型
能不用string尽量不用
使用float的地方尽量用double，64bit
（7）不改变的参数使用const
（8）参数个数不宜太多
如果过多，就要考虑接口的合理性了
（9）避免返回值与异常的同时返回


欢迎转发。


                    

                                                本文源自Google工程师joshua bloch的经验分享，楼主进行了整理和总结。


一、好接口的特性
（1）易学
（2）易用，甚至不需要文档
（3）难于误用
（4）容易阅读与维护
（5）容易扩展


二、接口设计实现的过程
（1）分析需求
考虑是否有更佳解决方案？
这是否使我们这真想要的需求？
（2）设计小接口
这个阶段，快速敏捷迭代
小接口易于修改
小接口的实现给人自信，减少挫败感
（3）高频、提早撰写接口
实现自测用例
（4）撰写服务提供接口（SPI：service provider interface）尤为重要
如果提供一个接口，是否就不支持第二个？
如果提供两个接口，是否能够扩展，融合？
如果提供三个接口，是否足够？能否工作正常？
（5）注意“正常的”异常维护
你的接口是为了满足所有需求？
即使有异常，也不要紧


三、接口设计的基本原则
（1）只做并做好一件事
函数名自解释；
不恰当的函数名，往往是不恰当设计的征兆
（2）如果没做到（1），就将函数分解
只增加，永远不要删除函数与接口
你永远不知道这个接口被谁在使用
（3）实现永远不能影响接口
举例：不能假定函数调用者只能使用hash
不能对外暴露实现细节
（4）最小化访问
尽量使用私有化成员
注意信息隐藏
（5）文档与注释
接口不是只写给自己（即使只给自己，也应该有说明）
（6）提高性能
（7）平台无关


四、类设计
（1）最小易变性
举例：Date不宜设计成类，过于易变；可设计为TimerTask
如果可变，则要设计良好、最小化的状态子集合
（2）尽量少用继承
如果设计一个类不能被继承，则应该明确禁止


五、方法设计
（1）不要到处拷贝模板代码
模块能做的事，不用到处拷贝方法
（2）原子性应该在一个方法内保证
（3）Fail-Fast设计原则
出错尽量早点返回，交给上层处理，不要勉强抢救
（4）避免数据直接访问，而是提供访问方法
（5）谨慎重载
小心多重继承中的误重载
可以重载的情况，也慎重考虑是否应该重载
（6）注意参数与返回值类型
尽量明确类型
能不用string尽量不用
使用float的地方尽量用double，64bit
（7）不改变的参数使用const
（8）参数个数不宜太多
如果过多，就要考虑接口的合理性了
（9）避免返回值与异常的同时返回


欢迎转发。