API设计随笔

今天看到CSDN上有一篇google的首席JAVA架构师访谈，主要谈到软件开发过程中的API设计。

 

总结之，有如下观点：

 

1。 关于测试API：在实现API之前编写它的测试用例。

2。 不用API写代码，就不可能看出API有什么问题。

3。 API设计有一条基本原则：疑则不用。

4。 你对API越来越有信心，代码也就越写越长。

 

结合到最近我做的系统设计中的API设计，颇有体会。

 

在理想化的设计过程中（文档级别），我已经把数据API的数据流理论上跑通了。

但是实现过程中总会出现各种各样的问题，举例

 

1。 有时会想到，咦，这个地方是不是得加一个参数，那个地方参数形式是否合适。

2。 开发人员甚至都有时会有疑惑，这个参数为什么要传，到底是有什么用？

3。 开发过程中也许会发现，为了使得API能正常调用，还必须对输入参数作各种限制，那么这种限制是该在接口级别体现还是在API的实现过程中体现呢？

4。 若已经针对该接口做了大量调用，或者上下游都已经调通了，修改接口的时候怎么办呢？

 

在少量的变化的情况下，我比较倾向于代码级的修改。

如果是接口的形式需要变化，那么我倾向于再普通接口上设置Adapter。

在复杂系统调用过程中，尽量让调用者和数据的实际使用者只通过接口耦合，若在中间层作过多的处理只会导致牵一发动全身。

关于“疑则不用”，还有对接口的“信心”，我想这是每个API开发人员应该遵循的原则，开发API最大的成功就是让调用者没有疑惑，没有顾虑。（当然这跟接口所完成业务的复杂度相关）

对于复杂接口，我倾向于在接口注释中说明使用方法。