Go 中空接口的最佳实践？

Question

我正在学习空接口。我发现，虽然有很多解释 - 也关于Stackoverflow - 关于空接口的含义以及它们如何工作，但关于何时/为什么使用它们，何时避免，注意事项是什么以及选择使用它们的利弊的最佳实践信息很少。在Go聊天室中，我读到了一些关于最好避免尽可能避免使用空界面的讨论，但没有适当的参数。其他人自豪地回应说，他们的代码设计中没有空接口。我最感兴趣的是使用库和框架（旨在被其他人重用/扩展）。现在我正在阅读一个包含相关库的框架代码库，该代码库在许多地方都充满了emtpy接口。其中一些让我感到困惑，我想知道是否所有用法都是有道理的。就像框架提供“用户管理”之类的东西一样，都是空的界面。在代码中（在数据库层附近）中，用户的电子邮件在技术上被视为用户首选项。在接口定义中更具体不是更好吗？AppConfigurationUserPreferences

Answer 1

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

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

func AddOne(n interface{}) int64 {

    switch nn := n.(type) {

        case int:

            return nn + 1

        case int8:

            return nn + 1

        // ... etc...

    }

}

但是，如果我将0.42（float64）传递给此函数或字符串怎么办？如果函数接受int64（），那么我们将在编译时收到有关此的警告，但是由于一切都是有效的，因此您不会得到任何东西。"asd"func AddOne(n int64) int64interface{}

你能做的最好的事情就是在运行时处理这个问题，或者panic（）或返回一个错误;这显然比编译时错误要清晰得多。

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

我必须特别看到这些和函数的细节，但是使用空接口有一些很好的理由;例如，当您想要接受某些自定义结构，然后使用反射根据某些外部数据在结构上设置值时。这本质上是诸如此类的软件包所做的，但它也通常用于解析某些配置文件等。AppConfigurationUserPreferencesencoding/json

这听起来像并且可能适合这一点，因为库/框架不知道你的应用程序配置需要什么设置，或者有什么用户首选项。但就像我说的，如果没有细节，很难确定。AppConfigurationUserPreferences

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

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

Answer 2

空命名接口在 Go 中没有意义，因为与 C# 等其他语言不同，例如，如果任何类型（C# 中的类）与接口签名匹配，则可以将其强制转换为特定接口。因此，在Go中，“类”（结构类型）不需要从接口继承（例如，在类型定义时声明接口）。

所以你的问题的答案：

Go 中空接口的最佳做法是不在 Go 中定义命名的空接口。

更新：感谢下面的评论，我已经改变了主意，我同意使用空命名接口的用例有限，以便文档和在IDE中更快地导航。