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

让我们跳到一个例子。在标准的Go lang库中，有一个Pusher接口，它执行一件事"推送启动HTTP / 2服务器推送"。
这是它的定义：

https://golang.org/pkg/net/http/#Pusher

很好的例子。但是，一些同事为他的实现辩护，该实现包含名称后缀为er的两个以上方法。
主要论点是，有stdlib的接口违反了这样的规则。他提到了接口ReadCloser。

查看其定义：

https://golang.org/pkg/io/#ReadCloser

我可以说是错误的假设。接口本身嵌入了另外两个接口。我该怎么解释？不违反规则。

您将如何解释这种情况？

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

但是，golang被认为是很自以为是的，并且因为我认为标准非常重要，所以我将坚持不成文的规则，以及如何进行调和，这本质上是ReadCloser很好的原因，但是有些其他er接口可能不是。

我将解释ReadCloser不违反"规则"(我将其更像是约定)。我有很多论点，为什么我会说它没有违反约定：

1.这不是一个独立的界面

ReadCloser接口不是一个自包含的接口。这是一个组合界面。它的名字反映了这一点。它连接Read和Close(您所需要的接口中的2个功能)，并添加er后缀。两种功能的实现方式以及它们的来源与接口无关。如果您阅读了一些内容，那么很有可能您也需要关闭资源。合并两个接口才有意义，因此可以使用保证Reader和Closer功能均可用的类型。

2.名称一定不会断断续续

与准则类似，应避免WRT软件包名称混乱。特别是如果它没有增加任何价值。从技术上讲，人们可能会争辩说接口应该称为ReaderCloser，但是该名称是否传达了名称ReadCloser不能传达的任何内容？当然不会。后者不再重复后缀，而且读起来更容易。

3. er接口和CamelCasing

单功能er接口(例如Stringer或Publisher)的示例确实被剪切