Functional options for friendly APIs

June 14, 2020

在一些框架代码中,比较常见的封装配置的方法是使用WithXXX()的API形态对外暴露接口,而非传统的Config配置数据结构。本文解释了配置API的集中方案。

一个server package的列子

Loading...

Server暴露出来的API非常简单清晰,但是毫无扩展性。

功能扩展

最简单直接的方法,可能就是增加参数了。

Loading...

带来的问题:

  1. 无法向前兼容的问题
  2. 默认值怎么填?如果我们不关心超时,clientTimeout要填什么?

可以根据使用场景,提供不同的constructor,但是这种方法过于笨重了。

Loading...

可配置

将配置单独抽离成Config。

Loading...

优点:

  1. 向前兼容,增加参数对老版本兼容
  2. 文档化更方便,在Config中针对每项配置说明即可。

但是还是没有解决默认值的问题,很多时候大部分参数用户是不想去理解的。

"I just want a sever, I don't want to have to think about it"

为了避免默认值带来影响,用户在调用的时候对不需要的参数不填默认值。

Loading...

Functional Options

另一种方法就是将配置拆分成多份,以可变参数的方式传入settler:

Loading...

可以将各种setter function封装在package中,不用直接对外暴露config的内部数据结构,而是暴露API。

一个完整的demo如下:

Loading...
See all postsSee all posts