如何设计接口
2014-10-15 23:33
211 查看
根据资料和经验总结。
要求:
命名:
命名规则和风格统一、规范;
命名清晰明确,不冗余,不模糊;
有意义:清晰和有意义的命名比简略而模糊的命名更应受到青睐;
功能
职责明确:功能尽量单一;
充分理由:不要随便有新功能就增加新接口;无意义的接口只会增加维护的难度;
将功能层和策略层分开:
功能是基础数据,不易变;
策略是表层数据,易变——策略可以使用参数修改;
低耦合:减少不同接口间的依赖。
一个接口不应随着另一个接口的变化而变化;
一个接口不应以某几个接口为前提而存在。
完备性:
考虑各种参数变化的情况;
考虑各种参数为default或为0的情况;
可扩展性:为以后可能会增加的参数预留余地,尽量不要写死;
参数
不超过5个;
从做到右,按照参数容易变化的程度排列;
尽量提供默认值;
若超过5个,把相似的数据放入到一个json或list等数据结构中;
禁止随意扩展:理由见“功能”部分;
参数尽量是原生数据结构,少用对平台依赖的数据结构。
分析角度:明确角度,不要一会以角色设计,一会以功能设计。
必要信息:
初始信息
初始化是否完毕
初始化完毕后的基本信息(如:list或dict的长度——可以看出是否为0)
中间信息
数据源是否变动
数据长度是否改变(需要视重要程度决定是否需打印该信息)
返回信息
是否成功?
失败原因?
参考文献:
/article/1230026.html
要求:
命名:
命名规则和风格统一、规范;
命名清晰明确,不冗余,不模糊;
有意义:清晰和有意义的命名比简略而模糊的命名更应受到青睐;
功能
职责明确:功能尽量单一;
充分理由:不要随便有新功能就增加新接口;无意义的接口只会增加维护的难度;
将功能层和策略层分开:
功能是基础数据,不易变;
策略是表层数据,易变——策略可以使用参数修改;
低耦合:减少不同接口间的依赖。
一个接口不应随着另一个接口的变化而变化;
一个接口不应以某几个接口为前提而存在。
完备性:
考虑各种参数变化的情况;
考虑各种参数为default或为0的情况;
可扩展性:为以后可能会增加的参数预留余地,尽量不要写死;
参数
不超过5个;
从做到右,按照参数容易变化的程度排列;
尽量提供默认值;
若超过5个,把相似的数据放入到一个json或list等数据结构中;
禁止随意扩展:理由见“功能”部分;
参数尽量是原生数据结构,少用对平台依赖的数据结构。
分析角度:明确角度,不要一会以角色设计,一会以功能设计。
必要信息:
初始信息
初始化是否完毕
初始化完毕后的基本信息(如:list或dict的长度——可以看出是否为0)
中间信息
数据源是否变动
数据长度是否改变(需要视重要程度决定是否需打印该信息)
返回信息
是否成功?
失败原因?
参考文献:
/article/1230026.html
相关文章推荐
- DAO接口如何设计?
- code complete之如何设计类接口
- [转]如何正确合理的设计一个接口项目
- 如何做一个简单的开放接口(1)-功能设计
- 如何正确合理的设计一个接口项目
- 如何使用form嵌套和接口来设计一个复杂的用户界面
- 用LPC1114做产品-如何设计程序下载接口flashmagicISP
- Java抽象类和接口的区别,及如何选用,为什么这样设计。
- 设计接口时应该如何设计业务异常?
- 如何设计接口?
- 如何设计接口
- 如何设计接口测试用例
- 如何设计接口?
- 如何设计接口原则?
- 如何正确合理的设计一个接口项目
- 如何架构、设计与实现高质量的远程接口
- 如何设计接口的参数以减少对接口的修改
- 如何设计接口呢?
- 如何设计一个异步Web服务——接口部分
- 了解如何设计和开发基于Http请求的数据接口服务系统