GoLang 接口名称及其方法数量的规则
Rule for GoLang Interface name and its number of methods
我在工作中讨论过接口名称和方法编号之间的相关性。
特别是，对于名称中以 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。
查看其定义：
type ReadCloser interface {
Reader
Closer
}
https://golang.org/pkg/io/#ReadCloser
我可以说它的假设是错误的。接口本身嵌入了另外两个接口。我怎么解释？没有违反规则。
你会如何解读这样的案例？
这个问题可能会被关闭，因为它被认为是基于意见的，或者与代码无关，或者其他原因...
然而，golang 被认为非常固执己见，而且因为我认为标准非常重要，所以我将加入我对不成文规则的看法，以及我将如何调和，本质上为什么 ReadCloser很好，但其他一些 er 接口可能不是。
我会将 ReadCloser 解释为不违反 "rule"（我更愿意称其为惯例）。为什么我会说它没有违反约定，我有很多论据：
1。它不是一个独立的界面
ReadCloser 界面不是独立的界面。这是一个组合界面。它的名字反映了这一点。它连接了 Read 和 Close（您之后的界面中的 2 个函数），并添加了 er 后缀。这两个功能是如何实现的，以及它们来自哪里与接口无关。如果您阅读了一些内容，很可能您也需要关闭该资源。只有结合这两个接口才有意义，因此您可以使用保证 Reader 和 Closer 功能都可用的类型。
2。名字不能口吃
很像 WRT 指南 package names 口吃是要避免的。特别是如果它不增加任何价值。从技术上讲，有人可能会争辩说接口应该被称为 ReaderCloser，但是这个名称是否传达了名称 ReadCloser 未传达的任何信息？当然不是。后者不重复后缀，读起来更容易。
3。 er 接口和 CamelCasing
单功能 er 接口的示例，如 Stringer 或 Publisher 确实是简单的。 Stringer 包含 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 接口中。
我在工作中讨论过接口名称和方法编号之间的相关性。
特别是，对于名称中以 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。
查看其定义：
type ReadCloser interface {
Reader
Closer
}
https://golang.org/pkg/io/#ReadCloser
我可以说它的假设是错误的。接口本身嵌入了另外两个接口。我怎么解释？没有违反规则。
你会如何解读这样的案例？
这个问题可能会被关闭，因为它被认为是基于意见的，或者与代码无关，或者其他原因...
然而，golang 被认为非常固执己见，而且因为我认为标准非常重要，所以我将加入我对不成文规则的看法，以及我将如何调和，本质上为什么 ReadCloser很好，但其他一些 er 接口可能不是。
我会将 ReadCloser 解释为不违反 "rule"（我更愿意称其为惯例）。为什么我会说它没有违反约定，我有很多论据：
1。它不是一个独立的界面
ReadCloser 界面不是独立的界面。这是一个组合界面。它的名字反映了这一点。它连接了 Read 和 Close（您之后的界面中的 2 个函数），并添加了 er 后缀。这两个功能是如何实现的，以及它们来自哪里与接口无关。如果您阅读了一些内容，很可能您也需要关闭该资源。只有结合这两个接口才有意义，因此您可以使用保证 Reader 和 Closer 功能都可用的类型。
2。名字不能口吃
很像 WRT 指南 package names 口吃是要避免的。特别是如果它不增加任何价值。从技术上讲，有人可能会争辩说接口应该被称为 ReaderCloser，但是这个名称是否传达了名称 ReadCloser 未传达的任何信息？当然不是。后者不重复后缀，读起来更容易。
3。 er 接口和 CamelCasing
单功能 er 接口的示例，如 Stringer 或 Publisher 确实是简单的。 Stringer 包含 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 接口中。