GoLang 接口名称及其方法数量的规则

Question

我在工作中讨论过接口名称和方法编号之间的相关性。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我可以说这是错误的假设。接口本身嵌入了另外两个接口。我怎么解释？没有违反规则。你将如何解读这样的案例？

Answer 1

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

然而，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接口中。