SUHAHA

在Go中使用'self'作为receiver变量是一种好的实践吗?

原文链接: stackoverflow.com

原帖:stackoverflow

原问题

我回忆了一下,没有任何博客或者视频的作者在Go中以selfthis作为方法的receiver,但是在stack overflow的很多问题下面就经常能看见有人以selfthis作为方法的receiver。这让我感到疑惑,用self作为receiver名有什么问题吗?

好像曾经在哪里看到过有人说receiver并不完全是一个指向自身的指针,谁能解释一下这种说法吗。把self看做指向自身的指针有什么问题吗?

例子:

type MyStruct struct {
  Name string
}

那种方式比较合适呢,还是两种都ok?

func (m *MyStruct) MyMethod() error {
  // do something useful
}

or

func (self *MyStruct) MyMethod() error {
  // do something useful
}

回答

其他的人都说的很好了,我再补充几点重要的:

以普通函数的方式调用Method Set里的方法

在Go里,不但可以通过receiver的方式调用一个方法,还可以像一个普通的函数一样调用。在type的名称后跟上相应方法的名称并将receiver作为第一个参数传入(这种使用方式叫做使用method expression)。

demo:

package main

import "fmt"

type Foo int

func (f Foo) Bar() {
    fmt.Printf("My receiver is %v\n", f)
}

func main() {
    a := Foo(46)
    a.Bar()
    b := Foo(51)
    Foo.Bar(b)
}

运行结果:

My receiver is 46
My receiver is 51

可以看出来,你手动调用并赋予了执行的上下文环境,使得self失去了他的语义,与面向对象编程中广泛引用的一句话“调用一个对象的方法就是给这个对象传递信息”的概念没有一点联系。

总的来说,在Go里方法其实就是将函数语义化地绑定在指定type上,并接受一个叫做receiver的参数,不管你以哪种方式调用方法,调用过程其实都是一样的。与大多数主流语言不同,Go并没有将方法调用的细节隐藏起来。

receiver并不一定能在方法内部被改变

在上面的demo中可以看到我定义了一个Bar()方法,他的receiver并不是一个指针类型,如果试着在方法内部为receiver赋值就会发现赋值是可以赋值,但是并不会影响到方法的调用者,因为receiver的值(Go中所有的值都一样)是按值传递的(所以这里的receiver只是调用者的一份拷贝)。

为了能在方法里改变receiver能影响到方法调用者,你需要定义一个指针类型的receiver:

func (f *Foo) Bar() {
    // here you can mutate the value via *f, like
    *f = 73
}

例子中的方法接收了一个确定类型的值,可以看出使用self表示“自身”已经毫无意义了。这与传统面向对象语言默认将对象按引用传递不同,在Go里你可以在任何东西“里”定义方法(包括在方法上定义方法,net/http标准库就是这么做的),“对象里的方法”这种概念已经不复存在了。

同样的值在不同时候可以有不同的方法

在Go里,方法可以非常方便用与组织特定类型的各种功能。在代码执行期间,同样的值可以拥有有不一样的方法,结合Go提供的接口,鸭子类型的编码风格,使得这种(动态织入方法)编码方式非常流行。我们经常能看到编码时会定义一个“Support”类型,在其中放很多为其他不同类型提供的方法。

标准库sort就是一个很好的例子:在sort包里提供一种IntSlice类型,这种类型允许你对整数类型的slice([]int)进行排序。只要将slice转换为IntSlice之后就拥有了各种对slice进行排序的方法,并且排序时原来的slice值并不会被改变(因为IntSlice就是type IntSlice []int)。很难去说IntSlice里的所有方法的receive带有self这层含义,因为这里所有的方法都是提供给其他类型使用的。从哲♂学的角度上看,这些工具类型并不存在“self”的概念。

总结

所以,不要给自己的思维加上太多枷锁,并不一定要使用语义化的方式去解释Go所提供的清晰明了的编码哲学。我自己对Go语言的学习理解来看,Go语言首要的编码风格应该是实用(与务虚相反)。所以每当你“感觉”某些概念很不自然,你就可以试着去弄清楚为什么这些东西在Go里要这样设计,大多数情况你最后会发现这种设计真是精妙。(我觉得熟悉C语言对于理解Go语言里methods设计有很大的帮助,更有助于理解这个问题。)