What is the need of method in golang

What is the need of method in golang. What are the advantages of method comparing with the function (receiver type) is okay?. What is the main goal?

Any method is really just a function. For example, this is valid Go code:

package main

import (
	"fmt"
)

func main() {
	var d Demo = 123

	// as a method
	fmt.Println(d.Add(123))

	// as a function
	fmt.Println(Demo.Add(d, 123))
}

type Demo int

func (d Demo) Add(a int) int {
	return int(d) + a
}

On the Go Playground: Go Playground - The Go Programming Language

To your point, I can’t think of any specific situation where you can’t replace a method with a similar function or closure to achieve the same end results. Even if you needed a function that matched a specific definition like func(int) int, you could use a closure instead of a method. For example:

package main

import "fmt"

func main() {
	d := Demo{
		something: 123,
	}

	// With a method
	fmt.Println(AcceptsFn(d.DoStuff))

	// With a closure
	fmt.Println(AcceptsFn(func(a int) int {
		return Demo.DoStuff(d, a)
	}))
}

func AcceptsFn(fn func(int) int) int {
	ret := 0
	for i := 0; i < 10; i++ {
		ret += fn(i)
	}
	return ret
}

type Demo struct {
	something int
}

func (d Demo) DoStuff(a int) int {
	return d.something + a
}

On the Go Playground: Go Playground - The Go Programming Language

So back to your questions:

What is the need of method in golang. What are the advantages of method comparing with the function (receiver type) is okay?. What is the main goal?

Technically I don’t think there is any need. They are just a helpful feature of the language that can make code cleaner and easier to read, write, and maintain. Similarly, we don’t need strings, but I suspect writing Go code would be a lot more annoying without them.

If you attach a function to a receiver, it becomes a method. This is the way how you do object oriented programming in Go. Sometime it makes full sense, sometimes not, but this is the same as in other languages. You will get better feeling when you get more experience.

One valid reason is to cleanly implement interfaces. For example, in an auth plugin I wrote for mosquitto, I declare the following interface:

type Backend interface {
	GetUser(username, password string) bool
	GetSuperuser(username string) bool
	CheckAcl(username, topic, clientId string, acc int32) bool
	GetName() string
	Halt()
}

I have a bunch of structs that implement those methods, so later I can just check users authorization against all available abckends by calling the method on any of those structs without having to know its type or implementations like this:

   for _, bename := range backends {

		if bename == "plugin" {
			continue
		}

		var backend = commonData.Backends[bename]

		log.Debugf("checking user %s with backend %s", username, backend.GetName())

		if backend.GetUser(username, password) {
			authenticated = true
			log.Debugf("user %s authenticated with backend %s", username, backend.GetName())
			break
		}
	}

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.