GoLang 接口名称及其方法数量的规则 [关闭]

Question

我在工作中讨论过接口名称和方法编号之间的相关性。 特别是，对于名称以er 结尾的后缀符号的接口，有一条不成文的规则。 规则说这样的接口应该包含一个方法。

让我们来看一个例子。在标准的 Go 语言库中，有 Pusher 接口做一件事“推送启动 HTTP/2 服务器推送”。 这是它的定义：

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

我可以说这是错误的假设。接口本身嵌入了另外两个接口。我如何解释？没有违反规则。

您将如何解释这种情况？

Answer 1

这个问题可能会被关闭，要么是因为它被认为是基于意见的，要么是与代码无关的，或者其他什么......

然而，golang 被认为是相当固执己见的，因为我认为标准非常重要，所以我会提出我对不成文规则的看法，以及我将如何调和，基本上为什么 ReadCloser 很好，但有些其他er 接口可能不是。

---

我将ReadCloser 解释为不违反“规则”（我将其称为更像是约定）。我有很多论据为什么我会说它不违反公约：

1。它不是一个独立的界面

ReadCloser 接口不是独立的接口。这是一个组合界面。它的名字反映了这一点。它将Read 和Close （您所追求的界面中的两个函数）连接起来，并添加er 后缀。这两个功能是如何实现的，以及它们来自哪里与接口无关。如果您阅读了某些内容，您可能也需要关闭该资源。只有将这两个接口组合起来才有意义，因此您可以使用保证Reader 和Closer 功能都可用的类型。

2。名字不能口吃

很像 WRT package names 的指导方针，要避免口吃。特别是如果它没有增加任何价值。从技术上讲，有人可能会争辩说该接口应该被称为ReaderCloser，但该名称是否传达了名称ReadCloser 未传达的任何内容？肯定不是。后者不重复后缀，更易读。

3。 er 接口和 CamelCasing

像Stringer 或Publisher 这样的单功能er 接口的例子确实很简单。 Stringer 包含 String 函数。故事结局。同Publisher接口。

您会注意到ReadCloser 接口是驼峰式，表明它是一种复合类型。只需将名称拆分为大写字符，并将后缀添加到每个部分。如果这些部分是真正的er 接口，并且复合接口是有意义的（参见第 1 点：如果您阅读，您可能需要关闭），那么它就是一个有效的复合接口。

无效er 接口的示例如下：

type FileReader interface {
    ReadCloserer
    ScanDir(string) ([]string, error)
    IsFile(string) bool
    Open(string, string) error
    // and so on
}

此接口包含太多 BS 函数，无法打包到 FileReader 接口中。