如何提高设计 API 的能力?

请注意,本文编写于 1842 天前,最后修改于 385 天前,其中某些信息可能已经过时。

from:?http://z.ihu.im/u/BZp(7

1、依赖倒置原则

依赖倒置的意思,是不要想象别人应该怎么用你的API、以及用你的API做什么;而是“倒”过来想,我的API对外提供了一个什么样的抽象、这个抽象是否够好、够简洁,有没有把不必要的细节暴露给用户。

比如说,之前我所在的公司做了个类似电子商城的东西,其它项目组做出产品,就放在这个商城里面销售。

那个商城团队就犯了干涉他人实现的大忌:他们非要了解其他项目组的逻辑,才知道如何才能把别人的产品上架销售。不要这样。

这种做法就导致两个团队耦合过重;且新产品和老产品逻辑无法兼容、甚至因为修改逻辑去迎合新产品,导致老产品销售逻辑出现问题——又因为怕老产品出现问题,于是不得不逼新产品去适应老产品的流程,而不管两者差别有多大。

这就导致,我们经常花1个月实现了一个新产品;为了把它上架却经常需要3个月甚至超过半年——并且,商城团队和其它项目团队都必须加班、修改逻辑,甚至经常因为商城方提出的诡异逻辑/需求而出现摩擦(这伙人傻的……我都忍不住发过几次火……

实在看不下去,我就给了一个方案,要求商城团队修改。

这个方案基于依赖倒置原则,要求商城对外提供一个商品的抽象;商品的定义是有名字有价格、通过销售转移所有权的逻辑实体。

如此一来,任何项目想要上架,只要给自己起个名字、定个价格、用html或某种富文本格式或商城项目组喜欢的任何格式提供一段商品介绍、最后再提供一个“所有权成功转移给xx用户”的回调接口即可。双方从此再不需要哪怕一个字的交流。

这个接口可以永远不修改哪怕一个字节,足以支持任何商品种类的交易。

(事实上,我们团队就是按这个要求写程序的。写完再和商城团队扯皮。这可以避免他们动辄增加的猪逻辑/需求影响到我们的内部结构:随便他们要什么,我们都可以弄个空逻辑或者不同商品规格搪塞过去)

但商城团队觉得一旦做成这样,他们以后就没事可干了,所以拒绝修改……

好在,后来他们集体辞职了。

——如果你的接口不能稳定,那么你一定违反了依赖倒置原则,或者是做了一个超烂的抽象。

——至于什么叫好抽象,请参考KISS原则

2、完整且最小原则

完整,就是接口的功能要完整,该有的功能必须有;最小,是接口功能没有冗余,不要接口A提供的功能,用一点外部逻辑再加上接口B或者接口B+接口C也能实现。

当然,这是一个比较理想化的指标。某些时候,为了易用性或者性能,是可以甚至必须做一些更简单、方便、易用,但加起来却不是最简的接口的。

但,这个完整且最小的接口必须找出来。它是一切的基础,也体现了开发者是否已经做出了一个清晰的抽象。

有了它,其它可以以后慢慢补;但如果没有这个基础,什么易用、简洁,都不过是扯淡。

我宁可用一个繁琐、难用、难理解,但可保证不变的接口,也不想碰做点简单的活计非常方便、易用,但根本没法实现稍难的需求、并且不能保证稳定的接口。

事实上,两者的差别就在于有没有好的抽象;而一旦有了好的抽象,哪怕想做得繁琐、难用、难理解,都不是容易的事。

总结:有了好的抽象,接口才可能稳定;然后找出完整且最小的接口,那么只要抽象不变,这个接口就绝对稳定;最后,在这个基础之上,做出易用、易理解的接口。

添加新评论