<p>What differentiates methods from functions?</p>
<p>When is it appropriate to use a method? </p>
<p>I cant grasp its usefulness. I've looked at multiple examples and it just seems i can make a function that does exactly what i want without the errors flying my way.</p>
<hr/>**评论：**<br/><br/>icholy: <pre><ul>
<li>Methods don't pollute the global namespace</li>
<li>One less parameter to pass.</li>
<li>Easier to read. (subjective)</li>
<li>Easier to search for "all methods on this type" than "all functions that take this type as a parameter".</li>
<li>Interfaces</li>
</ul></pre>Prerogativ: <pre><p>can you give an example were methods are useful vs regular functions?</p></pre>: <pre><p>[deleted]</p></pre>LimEJET: <pre><p>More importantly (and related to the point of not polluting the global namespace), you can define <em>several</em> <code>Area()</code>methods for different types:</p>
<pre><code>package main
import (
"fmt"
"math"
)
type Rectangle struct{
Width float
Height float
}
func (r *Rectangle) Area() float {
return r.Height * r.Width
}
type Circle struct{
Radius float
}
func (c *Circle) Area() float {
return 2 * math.Pi * c.Radius
}
func main() {
r := Rectangle{10, 5}
c := Circle{10}
fmt.Println(r.Area(), c.Area()) // prints: 50.0, 62.83185...
}
</code></pre>
<p>This can then be used with interface types containing <code>Area() float</code> to create functions that can be passed either a <code>Circle</code> or a <code>Rectangle</code>.</p></pre>danredux: <pre><p>Last point should be first IMO. Interfaces!!!</p></pre>drvd: <pre><p>Types implement interfaces if their method set covers the interface.</p>
<p>You cannot make a type satisfying an interface without the proper methods and this cannot be simulated by a function.</p>
<p>All the other points mentioned already are true too.</p></pre>bkeroack: <pre><p>Methods are useful when you have a bunch of functions that share common data. Eg, you find yourself writing several functions that all have parameters A and B--consider making them methods of a struct that contains A and B.</p>
<p>It's a bit of a false dichotomy though--they're all just functions.</p></pre>FUZxxl: <pre><p>Use methods when the method is an integral part of the type you define the method on. Use functions when it isn't. That's what I do at least.</p></pre>Prerogativ: <pre><p>so if have:</p>
<pre><code>type Player Struct{
Name String
Score int
}
</code></pre>
<p>i can create a method to set the name of a player and the initial score?</p></pre>FUZxxl: <pre><p>Yes. But as you seem to use public fields, why do you want to use getter and setter methods anyway? Don't use them if the field is public. They don't add anything.</p></pre>metakeule: <pre><p>I would use methods more for core functionality of a type and functions as extensions since they can be defined in / moved to other packages. </p></pre>sw0r6fish: <pre><p>Methods allow polymorphism which is the most important aspect of Object oriented programming. Go only allows polymorphism through implicit interfaces.</p>
<pre><code>car.move() and truck.move()
</code></pre>
<p>can both be accepted in a </p>
<pre><code>func(h Highway)acceptVehicle(vehicle interface{move()}){...}
</code></pre>
<p>method.</p></pre>
