【58沈剑架构系列】一分钟了解“好”接口的设计与实现
2018-01-15 11:26
357 查看
一、好接口的特性
易读
易用,难于误用
功能独立
容易扩展
二、好接口设计的基本原则
只做并做好一件事
函数名自解释
不恰当的函数名,往往是不恰当设计的征兆
如果没做到上一点,就将函数分解
只增加,永远不要删除函数与接口(你永远不知道这个接口被谁在使用)
实现永远不能影响接口
举例:不能假定函数调用者只能使用hash
不能对外暴露实现细节
最小化访问
尽量使用私有化成员
注意信息隐藏
注意文档与注释
接口不是只写给自己(即使只给自己,也应该有说明)
三、好接口实现的基本原则
不要到处拷贝代码
原子性尽量在一个接口内保证
Fail-Fast原则
出错尽量早点返回,交给上层处理,不要勉强抢救
避免数据直接访问,而是提供访问方法
注意参数与返回值类型
尽量明确类型
能不用string尽量不用
使用float的地方尽量用double,64bit
参数个数不宜太多
如果过多,就要考虑接口的合理性了
你见过没有注释的接口么?
你见过2000行的接口么?
你见过20个参数的接口么?
你见过什么更奇葩的接口?
【文章转载自微信公众号“架构师之路”】
易读
易用,难于误用
功能独立
容易扩展
二、好接口设计的基本原则
只做并做好一件事
函数名自解释
不恰当的函数名,往往是不恰当设计的征兆
如果没做到上一点,就将函数分解
只增加,永远不要删除函数与接口(你永远不知道这个接口被谁在使用)
实现永远不能影响接口
举例:不能假定函数调用者只能使用hash
不能对外暴露实现细节
最小化访问
尽量使用私有化成员
注意信息隐藏
注意文档与注释
接口不是只写给自己(即使只给自己,也应该有说明)
三、好接口实现的基本原则
不要到处拷贝代码
原子性尽量在一个接口内保证
Fail-Fast原则
出错尽量早点返回,交给上层处理,不要勉强抢救
避免数据直接访问,而是提供访问方法
注意参数与返回值类型
尽量明确类型
能不用string尽量不用
使用float的地方尽量用double,64bit
参数个数不宜太多
如果过多,就要考虑接口的合理性了
你见过没有注释的接口么?
你见过2000行的接口么?
你见过20个参数的接口么?
你见过什么更奇葩的接口?
【文章转载自微信公众号“架构师之路”】
相关文章推荐
- 【58沈剑架构系列】一分钟实现分布式锁
- 【58沈剑架构系列】一分钟了解负载均衡的一切
- 【58沈剑架构系列】一分钟掌握数据库垂直拆分
- 【58沈剑架构系列】一分钟写好连接池
- 【58沈剑架构系列】缓存架构设计细节二三事
- 【58沈剑架构系列】互联网架构,如何进行容量设计?
- 【58沈剑架构系列】100亿数据1万属性数据架构设计
- 【58沈剑架构系列】数据库架构设计的一切
- 一分钟了解“好”接口的设计与实现
- 基于.NET平台的分层架构实战(五)——接口的设计与实现
- 如何架构、设计与实现高质量的远程接口
- 【58沈剑架构系列】如何实施异构服务器的负载均衡及过载保护?
- 基于.NET平台的分层架构实战(五)——接口的设计与实现
- 【58沈剑架构系列】互联网架构为什么要做服务化?
- 【58沈剑架构系列】为什么说要搞定微服务架构,先搞定RPC框架?
- 基于.NET平台的分层架构实战(五)——接口的设计与实现
- 【58沈剑架构系列】互联网公司为啥不使用mysql分区表?
- 【58沈剑架构系列】秒杀系统架构优化思路
- 【58沈剑架构系列】究竟啥才是互联网架构“高可用”
- 【58沈剑架构系列】啥,又要为表增加一列属性?