我正在學習空接口。我發現，雖然有很多解釋 - 也關于Stackoverflow - 關于空接口的含義以及它們如何工作，但關于何時/為什么使用它們，何時避免，注意事項是什么以及選擇使用它們的利弊的最佳實踐信息很少。在Go聊天室中，我讀到了一些關于最好避免盡可能避免使用空界面的討論，但沒有適當的參數。其他人自豪地回應說，他們的代碼設計中沒有空接口。我最感興趣的是使用庫和框架（旨在被其他人重用/擴展）?，F在我正在閱讀一個包含相關庫的框架代碼庫，該代碼庫在許多地方都充滿了emtpy接口。其中一些讓我感到困惑，我想知道是否所有用法都是有道理的。就像框架提供“用戶管理”之類的東西一樣，都是空的界面。在代碼中（在數據庫層附近）中，用戶的電子郵件在技術上被視為用戶首選項。在接口定義中更具體不是更好嗎？AppConfigurationUserPreferences
2 回答
慕桂英3389331
TA貢獻2036條經驗 獲得超8個贊
在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{}
滄海一幻覺
TA貢獻1824條經驗 獲得超5個贊
空命名接口在 Go 中沒有意義，因為與 C# 等其他語言不同，例如，如果任何類型（C# 中的類）與接口簽名匹配，則可以將其強制轉換為特定接口。因此，在Go中，“類”（結構類型）不需要從接口繼承（例如，在類型定義時聲明接口）。
所以你的問題的答案：
Go 中空接口的最佳做法是不在 Go 中定義命名的空接口。
更新：感謝下面的評論，我已經改變了主意，我同意使用空命名接口的用例有限，以便文檔和在IDE中更快地導航。
- 2 回答
- 0 關注
- 126 瀏覽
添加回答
舉報
0/150
提交
取消