如果接口只有一個方法，我應(yīng)該使用函數(shù)類型嗎？以下是這兩種方法的示例：type Delegate interface { | type Delegate func(x int) int Do(x int) int | } | | type App struct { | type App struct { delegate Delegate | delegate Delegate} | } | func (this *App) foo() { | func (this *App) foo() { ... | ... y := this.delegate.Do(x) | y := this.delegate(x) ... | ...} | } | func main() { | func main() { delegate := &DelegateImpl{} | delegate := &DelegateImpl{} app := &App{delegate} | app := &App{delegate.Process} ... | ...} | }測試：type FakeDelegate { | t *testing.T | expectedX int | result int | } | | func (this *FakeDelegate) Do(x int) int { | require.Equal(t, this.expectedX, x) | return this.result | } | | 看起來右邊的代碼（帶有函數(shù)類型）的行數(shù)較少，尤其是在測試方面。但就沒有什么陷阱嗎？
2 回答
慕絲7291255
TA貢獻(xiàn)1859條經(jīng)驗(yàn) 獲得超6個贊
一般情況下
這是一個設(shè)計(jì)問題。接口提供了函數(shù)所沒有的東西：動態(tài)調(diào)度。因此，如果稍后您希望（可能是您自己的）客戶端代碼將所述函數(shù)應(yīng)用于對象，并設(shè)想該對象可能是程序中某個給定點(diǎn)的幾種不同類型之一，請選擇接口。
優(yōu)點(diǎn)：你可以變得靈活。
缺點(diǎn)：
動態(tài)分派的執(zhí)行時間開銷很小。例如，您不會希望在關(guān)鍵循環(huán)的中間出現(xiàn)這種情況。
接口（如果可用）將隨著系統(tǒng)的增長而使用，可能會以稍微出乎意料的方式使用。這意味著雖然大多數(shù)時候您可以輕松地定義函數(shù)的職責(zé)范圍，但作為設(shè)計(jì)決策，接口的職責(zé)和類型簽名應(yīng)該經(jīng)過深思熟慮。
對于試圖理解代碼的讀者來說，還有更多的知識間接要經(jīng)過。
Go 被設(shè)計(jì)為一種簡單實(shí)用的語言。我想作為有意愿的用戶，我們應(yīng)該發(fā)揚(yáng)它的理念。因此，我會說：如果您不需要某些東西，請不要使用它。:)
在您的特定情況下
盡管函數(shù)指針確實(shí)是開發(fā)人員管理的動態(tài)調(diào)度的一種形式，但在我看來，上述推理仍然適用：尋找可以滿足可預(yù)見需求的最簡單解決方案。否則 Go 將成為 Java。如果您確定委托永遠(yuǎn)不需要提供任何其他入口點(diǎn)（例如提供元信息），我會說堅(jiān)持使用函數(shù)指針。
幕布斯6054654
TA貢獻(xiàn)1876條經(jīng)驗(yàn) 獲得超7個贊
我認(rèn)為使用以下簡單規(guī)則是合理的：
如果最有可能的實(shí)現(xiàn)適用于未在參數(shù)中傳遞的數(shù)據(jù)，則使用接口。標(biāo)準(zhǔn)庫中的示例：
io.Reader具有單個方法的接口Read。否則使用函數(shù)。從標(biāo)準(zhǔn)庫的例子：
http.HandlerFunc，bufio.SplitFunc
我還發(fā)現(xiàn)好名字有助于設(shè)計(jì)決策。
- 2 回答
- 0 關(guān)注
- 207 瀏覽
添加回答
舉報(bào)
0/150
提交
取消