Golang Go语言中泛型类型参数太长且重复,有没有啥解决办法,或者我该换个实现思路?

发布于 1周前 作者 bupafengyu 来自 Go语言

问题背景:

- core.Biz 是个泛型类,包含一些通用的逻辑
- core.BizOptions 也是泛型结构,包含一些钩子函数供 core.Biz 调用

现在问题是,类型参数很长,且重复: image.png


Golang Go语言中泛型类型参数太长且重复,有没有啥解决办法,或者我该换个实现思路?

更多关于Golang Go语言中泛型类型参数太长且重复,有没有啥解决办法,或者我该换个实现思路?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html

20 回复

使用 type alias 然后把 BeforeCreate 做成字段,似乎能简练一点:
![img]( )

更多关于Golang Go语言中泛型类型参数太长且重复,有没有啥解决办法,或者我该换个实现思路?的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


……我觉得能用 interface 解决的就别用泛型。

别你觉得了,能泛型就泛型,对自己和别人都好点。

遇到这样的代码简直灾难

类或方法本身要和类型无关,才能设计为泛型类或者泛型方法。泛型参数的本质是用来传递类型信息,为了在末端能够获取到正确的类型来处理数据。

这个应该是想在执行前,记录日志,比如入参和返回值什么的吧。
说实话没有特别好的办法,要不要换个思路实现?中间件里实现不了吗?。如果是记录日志之类的远不如 java 中切面好用,除了那可恶的内存占用和巨大的胖 jar 。



> 能泛型就泛型,对自己和别人都好点

那些基础库, 例如数学的不同类型的, 或者涉及数组或 map 之类的容器遍历的, 用范型能简化代码
其他不必要性的场景, 硬上范型就是坑队友了
滥用范型会让代码越来越丑

在不适合的场景强上泛型

至今没用过泛型。。用不太习惯

可以使用 interface 限制一下
type Base interface {
~int | ~string | ~map[string]string
}

func Test[T Base](t T) {
fmt.Println(t)
}

func main() {
Test(“11”)
}

官方有提到,泛型的推荐应用场景是你对输入和输出类型都明确的情况下

没有太好的办法吧,要么不用泛型用 any ,要么用别名,rust 遇到这种问题也是用别名来解决

你这是不适合用泛型的强上…. 灾难

是应该用泛型的场景吗?

就这?看看 rust 的签名

我的 Rust 类型名字长达 3200 字符.webp

TS 的泛型好像更复杂。。。🤸‍♂️

从来没用过泛型无所畏惧

上范型就是坑,无法追踪代码错误
除非你输入明确类型,内部逻辑不复杂,并且输出类型单一

在Go语言中,泛型类型参数的确可能在某些情况下显得冗长且重复,这通常发生在需要定义多个类型参数,或者类型参数在多个地方被重复使用时。针对这一问题,有几种可能的解决方案或实现思路:

  1. 类型别名:如果类型参数组合在多个地方重复使用,可以考虑为这些组合定义类型别名。这样,在需要的地方只需引用别名,而不是列出所有类型参数。

  2. 简化泛型设计:重新评估你的泛型设计,看是否有可能通过减少类型参数的数量来简化代码。有时候,过于复杂的泛型设计可能并不是最佳选择,简单的接口或具体类型可能更易于理解和维护。

  3. 使用具体类型:如果泛型带来的好处并不明显,或者代码因为泛型而变得难以理解和维护,考虑使用具体类型替代泛型。这可能会牺牲一些灵活性,但可以提高代码的可读性和可维护性。

  4. 代码重构:如果泛型类型参数的使用确实非常频繁且冗长,考虑对代码进行重构,将重复的代码提取到单独的函数或方法中,以减少类型参数的重复。

总之,处理Go语言中泛型类型参数的冗长和重复问题并没有一劳永逸的解决方案。你需要根据具体情况,结合上述建议,选择最适合你的实现思路。在设计和实现过程中,保持代码的简洁性、可读性和可维护性始终是最重要的。

回到顶部
AI 助手
你好,我是IT营的 AI 助手
您可以尝试点击下方的快捷入口开启体验!