Go 中空接口的最佳实践？

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《Go 中空接口的最佳实践？》，本文主要会讲到golang等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

问题内容

我正在学习空接口。我发现虽然有很多解释——也包括 Stackoverflow——空接口的含义以及它们是如何工作的，但关于何时/为什么使用它们、何时避免、考虑什么的最佳实践的信息很少，以及选择使用它们的利弊。

在 Go 聊天室中，我读过一些关于最好避免使用空接口的讨论，但没有适当的参数。其他人自豪地回应说，他们的代码设计中的空接口为零。

我最感兴趣的是用于库和框架（旨在被其他人重用/扩展）。

现在我正在阅读一个带有相关库的框架代码库，它在许多地方都充满了 emtpy 接口。其中一些让我感到困惑，我想知道是否所有的用法都是合理的。AppConfiguration就像框架提供“用户管理”和类似的东西UserPreferences是空的接口。在代码中（靠近 db 层），用户的电子邮件在技术上被视为用户偏好。在接口定义中更具体不是更好吗？

正确答案

在 Go 聊天室中，我读过一些关于最好避免使用空接口的讨论，但没有适当的参数。其他人自豪地回应说，他们的代码设计中的空接口为零。

最大的问题是你输掉了所有的打字；例如，假设我有一个要对各种类型的数字进行操作的函数，所以我写：

func AddOne(n interface{}) int64 {
    switch nn := n.(type) {
        case int:
            return nn + 1
        case int8:
            return nn + 1
        // ... etc...
    }
}

但是如果我将 0.42 (float64) 传递给这个函数或字符串"asd"呢？如果函数接受一个 int64( )，那么我们会 在编译时func AddOne(n int64) int64收到一个警告，但你不会得到任何东西，因为一切都是有效的。 __interface{}

您能做的最好的事情就是在运行时处理这个问题，然后 panic() 或返回错误；这显然比编译时错误要清楚得多。

这是迄今为止最大的缺点。

我必须特别查看这些AppConfiguration和UserPreferences功能的详细信息，但是使用空接口有一些很好的理由；例如，当您想接受一些自定义结构，然后使用反射根据一些外部数据在结构上设置值时。这本质上是包之类的encoding/json功能，但它也常用于解析一些配置文件等。

这听起来像AppConfiguration并且UserPreferences可能适合这个，因为库/框架不知道您的应用配置需要哪些设置，或者有哪些用户偏好。但就像我说的，没有细节很难确定。

另一个用例是当你真的想接受各种各样的类型时；将参数传递给 SQL 查询是一个常见示例，或者fmt.Printf().

一般来说，避免interface{}可能是最好的，但如果你发现自己为此弯腰弯腰，那么最好只使用interface{}并忍受缺乏打字的情况。

好了，本文到此结束，带大家了解了《Go 中空接口的最佳实践？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！