我在工作中討論過接口名稱和方法編號之間的相關性。er特別是，對于名稱以 結尾的后綴表示法的接口，有一條不成文的規定。規則說這樣的接口應該包含一個方法。讓我們跳進一個例子。在標準的 Go 語言庫中，有Pusher一個接口可以做一件事“Push initiates an HTTP/2 server push”。這是它的定義：type Pusher interface { Push(target string, opts *PushOptions) error}https://golang.org/pkg/net/http/#Pusher好例子。但是，一些同事為他的實現辯護，該實現包含兩個以上的er名稱后綴的方法。主要論點是存在違反此類規則的 stdlib 接口。他指的是界面ReadCloser?？纯此亩x：type ReadCloser interface { Reader Closer}https://golang.org/pkg/io/#ReadCloser我可以說這是錯誤的假設。接口本身嵌入了另外兩個接口。我怎么解釋？沒有違反規則。你將如何解讀這樣的案例？
1 回答
慕田峪9158850
3.
TA貢獻1794條經驗 獲得超7個贊
這個問題可能會被關閉，因為它被認為是基于意見的，或者與代碼無關，或者其他......
然而，golang 被認為非常固執己見，并且因為我認為標準非常重要，所以我將加入我對不成文規則的看法，以及我將如何調和，本質上為什么它ReadCloser很好，但其他一些er接口可能不是。
我將其解釋ReadCloser為不違反“規則”（我更愿意稱之為約定）。為什么我會說它沒有違反公約，我有很多論據：
1.它不是一個獨立的界面
該ReadCloser界面不是獨立的界面。這是一個組合界面。它的名字反映了這一點。它連接Read和Close（您之后的界面中的 2 個函數），并添加后綴er。這兩個功能是如何實現的，以及它們來自哪里與接口無關。如果您閱讀了一些內容，很可能您也需要關閉該資源。Reader只有結合這兩個接口才有意義，因此您可以使用保證兩者和Closer功能都可用的類型。
2. 名字不能口吃
就像指南 WRT包名稱結巴是要避免的。特別是如果它不增加任何價值。從技術上講，有人可能會爭辯說應該調用該接口ReaderCloser，但是該名稱是否傳達了該名稱未傳達的任何信息ReadCloser？當然不是。后者不重復后綴，讀起來更容易。
3.er接口和CamelCasing
單功能接口的例子，er如Stringer， 或Publisher確實很簡單。AStringer包含String函數。故事結局。和界面一樣Publisher。
您會注意到該ReadCloser接口是 CamelCased，表明它是一種復合類型。只需將名稱拆分為大寫字符，并將后綴添加到每個部分。如果部件是真正的er接口，并且復合接口有意義（參見第 1 點：如果您閱讀，很可能需要關閉），那么它就是一個有效的復合接口。
無效er接口的例子是：
type FileReader interface {
? ? ReadCloserer
? ? ScanDir(string) ([]string, error)
? ? IsFile(string) bool
? ? Open(string, string) error
? ? // and so on
}
這個接口包含了太多的 BS 功能，無法打包到一個FileReader接口中。
- 1 回答
- 0 關注
- 154 瀏覽
添加回答
舉報
0/150
提交
取消