2

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

例子：

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:在需要时处理它。

4

3 回答 3

12

如果你真的需要可选参数（从 Go 标准库中可以看出，这种情况很少见），惯用的方法是为每个可选参数定义一个带有字段的结构，然后调用者可以传递一个带有字段的结构文字他们想要填写。

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

像 Python 这样的语言中的可选参数通常意味着 API 会不断增长，直到函数和方法的参数比任何人都记得的多，并且永远不清楚各种参数组合如何交互（而且它们的测试更少）。

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

于 2012-09-23T04:29:49.097 回答
6

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

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

于 2012-09-22T15:04:59.563 回答
0

这完全取决于您的项目要求，如果您的项目处于这种情况，那么没有任何不好的形式

仅针对这种情况提供了可选参数工具。

于 2012-09-22T13:29:20.583 回答