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