在我们日常的研发流程中，需要定义接口提供给调用方，实际设计时，工程师们却很容易把接口当作暴露功能的方式，而却忽略接口应该是服务提供方能力的体现。
换个说法，就是错误的理解了抽象这件事：仅仅把接口当成未来可以替换实现类的脚手架，而没有把它作为程序设计的基础。
大家翻开JDK的源码，看看jdk的api会发现大部分接口都是able结尾的，表示这是一种能力。比如驾驶汽车，只有人类具有，那么可以抽象成接口，接口表述的是一种组合关系，具有更强的扩展性，接口是一种能力的描述，能做什么，是一组功能或者方法的集合。
举个例子，差的工程师会设计一个带有“开灯”，“关灯”功能的接口，期望调用方能根据这个接口实现出不同样式的开关；而合格的工程师会设计出带“开”，“关” 能力的接口：既不会过于抽象，也不会过于局限。 好的设计应该由接口规划骨架之后，依靠实现填充血肉。过于抽象或者过于具体的接口连“骨架”的效果都达不到，更别提实现的好坏了。
接口设计应该在考虑程序结构和组件间的交互的基础上，描述组件的能力；而不是描述已经实现的某个组件的功能。如果两者冲突，更好的解决方案是增加适配器，而不是依照实现定义接口。
正确的API 设计一定是为调用方赋能，赋予调用方更大的能力，在已有的基础上创造更多的应用及场景。
描二维码或手动搜索微信公众号【架构栈】：ForestNotes
欢迎转载，带上以下二维码即可
点击“阅读原文”，所有【架构栈】近期的架构文章汇总
↓↓↓