为什么 Go 方法接收类型不能是接口？

Question

来自 有关方法声明的 Go 文档：

接收器类型必须采用 T 或 *T 形式，其中 T 是类型名称。 T 称为接收者基本类型或简称为基本类型。 基类型不能是指针或接口类型，并且必须在与方法相同的包中声明。

谁能给我一些关于为什么会这样的见解？是否有任何其他（静态类型）语言允许这样做？我真的很想在接口上定义方法，这样我就可以将给定接口类型的任何实例视为另一个接口类型。例如（从 关于模板方法模式的维基百科文章中窃取示例）如果以下内容是有效的：

type Game interface {
    PlayOneGame(playersCount int)
}

type GameImplementation interface {
    InitializeGame()
    MakePlay(player int)
    EndOfGame() bool
    PrintWinner()
}

func (game *GameImplementation) PlayOneGame(playersCount int) {
    game.InitializeGame()
    for j := 0; !game.EndOfGame(); j = (j + 1) % playersCount {
        game.MakePlay(j)
    }
    game.PrintWinner()
}

我可以使用任何将“GameImplementation”实现为“游戏”的实例，而无需任何转换：

var newGame Game
newGame = NewMonopolyGame() // implements GameImplementation
newGame.PlayOneGame(2)

更新：这样做的目的是尝试实现抽象基类的所有好处，而无需与显式的耦合 等级制度。如果我想定义一种新行为 PlayBestOfThreeGames，抽象基类将要求我更改基类本身 - 而这里我只是在 GameImplementation 接口之上定义一个方法

Answer 1

这可能与 Java 中无法在接口上定义方法的原因相同。

接口是对一组对象的外部接口的一部分或全部的描述，而不是它们如何实现底层行为。在 Java 中，如果您需要预定义部分行为，您可能会使用抽象类，但我认为在 Go 中做到这一点的唯一方法是使用函数而不是方法。

我相信对于你的例子来说，更惯用的代码会是这样的：

type GameImplementation interface {
    InitializeGame()
    MakePlay(player int)
    EndOfGame() bool
    PrintWinner()
}

func PlayOneGame(game GameImplementation, playersCount int) {
    game.InitializeGame()
    for j := 0; !game.EndOfGame(); j = (j + 1) % playersCount {
        game.MakePlay(j)
    }
    game.PrintWinner()
}

其中 PlayOneGame 和任何特定的游戏实现可能位于不同的包中。

以下是有关 golang-nuts 的一些讨论

Answer 2

回答您是否有其他静态类型语言允许这样做的问题：是的，大多数。任何具有多重继承的语言都允许类具有抽象方法和具体方法的任意组合。另外，请参阅 Scala 的特征，它类似于 Java 的接口，但可以有具体的方法。 Scala 也有结构类型，这实际上就是 Go 接口的全部内容。

Answer 3

您在 Interface 中描述的实际上是在其他地方可能被称为抽象类的内容 - 也就是说，定义了一些但不是全部方法的类，必须对其进行子类化才能实例化。

然而，Go 没有任何类层次结构的概念——整个类型结构是扁平的。类上的每个方法都是专门为该类定义的，而不是在任何父类、子类或接口上定义的。这是一个有意识的设计决定，而不是疏忽。

因此，在 Go 中，接口不是类型层次结构的组件（因为不存在这样的东西）。相反，它只是为了给定目的而必须实现的一组方法的临时规范。就这样。它们是动态类型的替代品，您可以提前声明将使用给定类型的哪些函数——然后可以使用类型满足这些要求的任何变量。

这使得在 Go 中使用泛型等模式变得不可能，Rob Pike 在一次会议上表示，如果有人能够提供优雅的实现和令人信服的用例，这种情况将来可能会改变。但这还有待观察。

Answer 4

首先，重要的是要注意类型隐式实现接口——也就是说，接口是“鸭子类型”。任何提供接口所需方法的类型都可以分配给接口类型的变量，而无需与原始类型进行任何合作。这与 Java 或 C# 不同，在 Java 或 C# 中，除了实际提供方法之外，实现接口的类还必须声明其实现接口的意图。

围棋也有相当强烈的反对“远距离行动”的倾向。例如，即使方法与类型分开声明，但在与其接收者类型不同的包中声明方法是非法的。您不能只是向 os.File 添加方法。

如果接口可以提供方法（使它们traits/roles），那么任何实现的类型一个接口会突然获得一堆新方法。阅读代码并查看所使用的这些方法的人可能很难弄清楚它们来自哪里。

脆弱性存在一个问题 - 更改接口所需的方法的签名，并且一堆其他方法会出现或消失。在他们失踪的情况下，他们“本来”来自哪里并不清楚。如果类型必须声明其实现接口的意图，那么违反约定将提示错误（并且“意外”实现接口不会执行任何操作），但是当隐式满足接口时，事情会变得更加棘手。

更糟糕的是，可能会出现名称冲突——一个接口提供的方法与实现该接口的类型提供的方法同名，或者两个接口都提供同名的方法，而某个类型恰好同时实现了这两个接口接口。解决这种冲突是 Go 真正希望避免的复杂情况，并且在很多情况下没有令人满意的解决方案。

基本上，如果接口能够提供方法，那就真的很酷了——角色作为可组合的行为单元很酷，并且与 Go 的组合优于继承的哲学很好地契合——但实际上这样做会太复杂，而且太单一了。 distance-y 供 Go 思考。