Go語言中的方法和函數


在C#或者Java里面我們都知道,一個Class是要包含成員變量和方法的,對於GO語言的Struct也一樣,我們也可以給Struct定義一系列方法。

一、怎么定義一個方法?

Go的方法是在函數前面加上一個接收者,這樣編譯器就知道這個方法屬於哪個類型了。例如:

package demo1

import (
   "fmt"
)

type Student struct {
   Name string
   Age int
   Class string
}

func (stu Student) GetUserInfo(student Student)  {
   fmt.Printf("學生姓名:%v 年齡: %v 班級:%v ",student.Name,student.Age,student.Class)
}

上面的代碼就是定義了一個Student的結構體,然后針對這個結構體,創建了三個方法。我們可以通過【實例名.方法名】的方式來訪問這個結構體內的方法。

package main

import "Function/demo1"

func main(){
   student:=demo1.Student{
      Name:"XiaoMing",
      Age:20,
      Class:"3-2",
   }

   student.GetUserInfo(student)
}

二、接收者的類型問題

上面的GetUserInfo的接收者是一個Student類型,這里就會出現一個問題,如果我是設定類的操作,那么不會改變對應實例的值,它只是一個拷貝。下面的例子將說明這個問題,下面這個Set方法接收者是Student

type Student struct {
   Name string
   Age int
   Class string
}

func (stu Student) SetStudentName(name string)  {
   stu.Name = name
}

main函數中使用這個類

func main(){
   student:=demo2.Student{
      Name:"XiaoMing",
      Age:20,
      Class:"3-2",
   }

   student.SetStudentName("LiLie")

   fmt.Printf("Name: %v",student.Name )
}

結果:

Name: XiaoMing

可以看到,這里並沒把Name進行修改。

如果我們使用Student指針類型作為接收者,則會修改這個值。例子如下:

func (stu *Student) SetStudentName(name string)  {
   stu.Name = name //這里為什么能stu直接.出Name,是Go的語法糖相當於 (*stu).Name
}

再次運營結果為:

Name: LiLie

三、何時使用值類型接收者,何時使用指針類型接收者。

粗暴的結論:如果你不知道怎么選擇,那就使用指針。但有時候,使用值接收者會更合理,尤其是效率考慮,比如:不需要修改的小 struct、基礎數據類型。以下是一些有用的指導方針:

- 如果接收者是 map、func 或 chan,不用使用指針。如果是 slice,並且方法不會 reslice 或 從分配 slice,不要使用指針;

- 如果方法需要修改接收者,必須使用指針; - 如果接收者是包含了 sync.Mutex 或類似的同步字段的結構體(struct),接收者必須使用指針,避免拷貝;

- 如果接收者是一個大的結構體或數組,使用指針會更高效。但多大是大?如果所有元素(struct 的字段或數組元素)作為方法的參數傳遞認為太大,那么作為接收者也是太大。(粗暴一些,所有元素內存超過指針大小,可以考慮使用指針);

- 如果接收者是結構體、數組或 slice,同時,它們的元素是指針,且指向的數據要改變,那么使用指針接收者會更合理;(有點繞,那就總原則:用指針沒錯);

- 如果接收者是小的數組,或小的沒有可變字段或指針的結構體,或者結構體字段只是簡單的基礎類型,值接收者會更合理;值接收者能減少垃圾回收的壓力,一般會優先分配在棧上(記住是一般,因為有可能逃逸);但除非有性能測試驗證,否則別因為可以介紹垃圾回收壓力,就選擇值接收者;

最后再強調一下,如果你拿不定主意,那就用指針接收者。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM