63 | 接口设计的准则

如何做接口设计？

开闭原则是架构课的灵魂

开闭原则的含义：

• 模块业务要稳定。模块的设计符合“只读”原则，每一个模块都应该是可完成的
• 模块业务的变化点应该使用接口或者callback回调出去,交给其他业务模块，应该引入插件机制将系统分解为最小化的核心以及正交分解的周边子系统。

什么是接口？

接口在不同的语义环境下，主要有两个不同含义。

• 模块的使用界面

也就是规格，比如公开的类或函数的原型

• 模块对依赖环境的抽象

接口是模块与模块之间的契约。它鼓励模块与模块的交互基于接口作为契约，而不是依赖于具体实现。

模块的使用界面

坚持KISS（Keep it Simple, Stupid）原则，追求简单自然，符合惯例。（“让傻子也能够看得懂”）

我们说接口要 KISS，要简单自然，这里很重要的一点是符合语言和社区的惯例。如果某类业务在语言中已经有约定俗成的接口

模块的环境依赖

模块另一种含义是模块对依赖环境的抽象，也就是模块与模块之间的契约。我们大部分情况下提到的接口，指的是这一点。

• 使用界面依赖

用户在使用该模块的使用界面时自然涉及的

• 实现依赖

模块当前实现方案中涉及到的组件，它带来的依赖条件。如果我换一种实现方案，这类依赖可能就不再存在，或者变成另外的依赖。

界面依赖细节

界面依赖与实现依赖到处置方式往往还是有所不同

使用界面依赖来说，我们接口定义更多考虑的往往是对参数的泛化与抽象，以便让我们可以适应更广泛的场景。

在接口参数的抽象上，也不适合过度。如果某种泛化它不会发生，那就是过度设计

实现依赖细节

• 直接依赖所基于的组件，
• 将所依赖的组件所有被引用的方法抽象成一个接口，让模块依赖接口而不是具体的组件

大部分情况下应该选择直接依赖组件，而不必去抽象它

如无必要，勿增实体

什么时候该当考虑把依赖抽象化？

1. 需要提供多种选择的时候。
2. 在需要解除一个庞大的外部系统的依赖时。
3. 在依赖的外部系统为可选组件时。

版权声明

引用所有内容归极客邦-极客时间所有

引用链接： https://time.geekbang.org/column/article/176852

标签: 架构, 模块, 系统, 周边, 核心, 业务, 接口, 子系统, 机制, 原则, 依赖, 抽象, 组件

本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。