Maison  >  Article  >  développement back-end  >  Pourquoi n'est-il pas recommandé d'utiliser this ou self pour le nom du destinataire en go ?

Pourquoi n'est-il pas recommandé d'utiliser this ou self pour le nom du destinataire en go ?

Go语言进阶学习
Go语言进阶学习avant
2023-07-21 13:23:26814parcourir

Dans le développement quotidien, en plus de définir des fonctions, nous définissons également certaines méthodes. Ce n'est rien, mais certains étudiants qui passent de PHP ou d'autres langages orientés objet​​à GO nomment souvent le nom du récepteur comme cethisselfme, self,
Attendez.

🎜🎜L'auteur a également rencontré des étudiants similaires dans le cadre du développement réel de projets. Après des rappels répétés mais en vain, j'ai décidé d'écrire cet article pour convaincre ces étudiants. 🎜

CR Standard Practice

Tout d'abord, jetons un coup d'œil à la dénomination standard recommandée par GOReceiver Names,以下内容摘抄自https://github.com/golang/go/wiki/CodeReviewComments#receiver-names:

The name of a method's receiver should be a reflection of its identity;
often a one or two letter abbreviation of its type suffices (such as "c" or "cl" for "Client").
Don't use generic names such as "me", "this" or "self", identifiers typical of object-oriented languages that gives the method a special meaning.
In Go, the receiver of a method is just another parameter and therefore, should be named accordingly.
...

简单翻译总结有如下2点:

  1. 方法接受者名称应反映其身份, 并且不要使用methisselfCes identifiants typiques des langages orientés objet.

  2. En go, le récepteur de la méthode est en fait un autre paramètre de la méthode.

Receiver est le premier paramètre de la méthode !

Le deuxième point ci-dessus n'est peut-être pas facile à comprendre, alors regardons la démo ci-dessous :

// T ...
type T int

// Println ...
func (t T) Println() {
	fmt.Println("value: %v", t)
}

func main() {
	t := T(1)
	t.Println()

	T.Println(t)
// receiver作为函数的第一个参数,这个时候发生值拷贝,所以方法内部的t变量是真实t变量的一个拷贝
// 这和this的含义是不相符的

}
// output:
value: 1
value: 1

通过上面的demo, 我们知道接受者可以直接作为第一个参数传递给方法的。而t.Println()应该就是Go中的一种语法糖了。

到这里可能有同学又要问了, 既然Go提供了这种语法糖,那我们这样命名有什么问题呢?笔者先不着急解释, 我们继续看下面的demo:

// Test ...
type Test struct {
	A int
}

// SetA ...
func (t Test) SetA(a int) {
	t.A = a
}

// SetA1 ...
func (t *Test) SetA1(a int) {
	t.A = a
}

func main() {
	t := Test{
		A: 3,
	}
	fmt.Println("demo1:")
	fmt.Println(t.A)
	t.SetA(5)
	fmt.Println(t.A)
	t1 := Test{
		A: 4,
	}
	fmt.Println("demo2:")
	fmt.Println(t1.A)
	(&t1).SetA1(6)
	fmt.Println(t1.A)
}
// output:
demo1:
3
3
demo2:
4
6

看上面的demo我们知道, 当receiver不是指针时调用SetA其值根本没有改变。

因为Go中都是值传递,所以你如果对SetA的receiver的名称命名为thisself等,它就已经失去了本身的意义——“调用一个对象的方法就是向该对象传递一条消息”。而且对象本身的属性也并不一定会发生改变。

综上: 请各位读者在对receiver命名时不要再用thisself等具有特殊含义的名称啦。

Receiver是可以为nil的!!!

最近在研读h2_bundle.go的时候,发现了一段特殊的代码,顿时惊出一身冷汗,姑在本文补充一下,以防止自己和各位读者踩坑。

源代码截图如下: Pourquoi n'est-il pas recommandé d'utiliser this ou self pour le nom du destinataire en go ?

惊出我一身冷汗的正是图中标红的部分,receiver居然还要判断为nil!在我的潜意识里一直是这样认为的,receiver默认都是有值的,直接使用就行了。这简直颠覆我的认知,吓得我赶紧写了个demo验证一下:

type A struct {
	v int
}

func (a *A) test() {
	fmt.Println(a == nil)
}

func (a *A) testV() {
	fmt.Println(a.v)
}


func main() {
var a *A
	a.test()
	a.testV()
}

上述输出如下:

Pourquoi n'est-il pas recommandé d'utiliser this ou self pour le nom du destinataire en go ?

a.test()能够正常输出,只有在处理变量结构体内部变量v才报出panic!!!还好本文前面已经介绍了Receiver是方法的第一个参数。正因为是第一个参数所以仅仅作为参数传递时即使是nilVous pouvez également appeler la fonction normalement et signaler une panique là où elle est réellement utilisée.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer