-3

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

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

type Pusher interface {
  Push(target string, opts *PushOptions) error
}

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

好的例子。但是，一些同事为他的实现进行了辩护，该实现包含两个以上带有erin name 后缀的方法。主要论点是有标准库的接口违反了这样的规则。他提到了界面ReadCloser。

看它的定义：

type ReadCloser interface {
        Reader
        Closer
}

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

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

你将如何解释这样的案例？

4

1 回答 1

2

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

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

我会解释ReadCloser不违反“规则”（我更喜欢称之为约定）。我有很多论点为什么我会说它不违反公约：

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

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

2.名字不能口吃

就像要避免WRT包名称口吃的指南一样。特别是如果它没有增加任何价值。从技术上讲，有人可能会争辩说应该调用接口ReaderCloser，但是这个名称是否传达了该名称未传达的任何内容ReadCloser？肯定不是。后者不重复后缀，更容易阅读。

3.er接口和CamelCasing

像, 或等单功能er接口的例子确实很简单。A包含函数。故事结局。与界面相同。StringerPublisherStringerStringPublisher

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

er无效接口的示例是：

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

该接口包含太多的基站功能，无法打包到一个FileReader接口中。

于 2019-01-16T12:13:05.440 回答