Go 这是泛型的有效用例吗

发布于06月06日

现在，在我的代码中，我有一堆重复的工作，看起来像这样.

type FP = func(arg1 string, arg2 int, arg3 []string) bool
func Decorator(fp FP, arg1 string, arg2 int, arg3 []string) {
    // Do some stuff prior to running fP
    res := fp(arg1, arg2, arg3)
    // Do some other stuff depending on res
}

我的问题是，每次我想用不同数量/类型的参数添加一个新的FP类型时，我都必须重新定义这个方法，所以我最终在我的代码中重新定义了4-5次修饰符，可能需要做更多的工作.我想把装修工换成

type FP = func(a ...interface{}) bool
func Decorator(fp FP, argDetails interface{}) {
    // do stuff
    res := fp(a)
    // do other stuff
}

并让FP断言类型.但我不确定这是否会导致问题/是一个糟糕的用例，因为我看到了很多关于不使用接口/会导致性能问题的东西.

推荐答案

泛型无济于事的原因有几个，特别是泛型only有助于类型，而不是参数的number.就我个人而言，我会以不同的方式解决这个问题:

func Decorator(fp func()) {
    // do stuff
   fp()
    // do other stuff
}

使用闭包调用它:

var res someType

Decorator(func() {
    res = originalFunc(arg1, arg2, arg3)
})

它在调用点有点冗长，但它完全适用于任何函数签名-任何数量或类型的参数以及任何数量或类型的返回值.它甚至可以与方法调用一起使用.这听起来像是你在做一些基于结果的逻辑，所以你也可以:

func Decorator(fp func() bool) {
    // do stuff
   res := fp()
    // do other stuff
}

var res someType

Decorator(func() bool {
    res = originalFunc(arg1, arg2, arg3)
    return res
})

即使修饰函数的返回值多于布尔值，或者如果您想使用其他逻辑(例如，如果它返回一个错误，您想要转换为布尔值为!= nil)，它仍然可以工作.