Golang：API 的可选参数设计

 

最近，我针对Dave Cheney的文章“友好API的功能选项” ，他分享了他对API可选参数设计的想法。 Dave最后提出了有关功能参数的建议，这些参数可以有选择地传递给类型构造函数。 毫无疑问，这种设计优于具有多个参数的单个构造函数。

然而：

Dave的设计在99％的用例中都显得过高，并且对这些API的维护者和使用者都施加了不必要的负担。

与这些API集成的开发人员是消费者 ，读者（也称为代码审阅者）也是消费者 。

我的建议

一个更简单的选择：两个构造函数，一个是默认构造函数，另一个接受配置结构。

这是我提出的设计戴夫在构造函数项 ：

我们得到的...

在使用方面

降低详细程度：减少符号term出现。 此好处的数量随可选参数的数量线性增加：

在维护方面

减少单元测试的数量：将选项集减少为一个值对象，使它们的测试变得不必要 。

我们失去的是……

在使用方面

据我所知。

符号Default清楚地表明了自定义Term的可能性，以便使用此API的开发人员将在需要时寻求替代方法。 这意味着该设计没有添加任何令人困惑的方面。

在维护方面

不适用 我们通过减少需要测试的工件数量来提高可维护性。

任何验证和/或计算都可以提取到其自身的构造函数类型的函数（无论是静态函数还是成员函数）。

翻译自: https://www.javacodegeeks.com/2019/08/golang-optional-arguments-apis.html