Question

如果我有一个函数，其中最后一个参数是可选的，那么使用...来允许参数是可选的，还是被认为是错误的形式是合适的做法？

示例：

func Foo(s ...string) {
    switch len(s) {
        case 0:
            fmt.Println("You didn't pass an argument")
        case 1:
            fallthrough
        default:
            fmt.Printf("You passed %s\n", s[0])
    }
}

Foo("bar")        // "You passed bar"
Foo()             // "You didn't pass an argument"
Foo("bar", "baz") // "You passed bar"

在这个例子中，我不在乎是否传递了太多的参数，但我可以在需要时在default:的情况下处理。

Answer 1

如果确实需要可选参数（正如您从Go stdlib中看到的那样很少见），惯用的方法是为每个可选参数定义一个包含字段的结构，并且然后调用者可以传递一个包含他们想要填写的字段的结构文字。

更常见的是提供替代函数或方法，当它只有一个或两个“可选”参数时，应该是大部分时间。

像Python这样的语言中的可选参数通常意味着API会增长和增长，直到函数和方法拥有的参数比任何人都记住的都多，并且从不清楚各种参数组合如何相互作用（并且它们的测试甚至更少）。 / p>

强制您为各种参数组合定义显式函数和方法需要更多地考虑您的API，但是从长远来看它会更加可用和可维护。

Answer 2

我不推荐这个。（ab）使用可变参数传递可选参数存在不同的问题。其中最重要的可能是最后arg ...T)的形式只允许一种类型。对于具有多个类型的多个可选参数，可以使用...interface{}，但这会导致不必要的运行时（un）装箱成本，并且缺少任何（有用的）编译时类型检查。

另一个可能的反对意见是，我认为你不会在标准库中的任何地方找到一个示例/先例，这被一些人视为非正式的Go编码风格指南。

Answer 3

这一切都取决于您的项目要求，如果您的项目处于这种情况，那么没有任何不良形式

仅为此类情况提供可选参数工具。

变量函数是可选参数的合适解决方案吗？

3 个答案: