<p>NOOB question:</p>
<p>When should a method be defined as </p>
<p>func (parent *a) method() {
}</p>
<p>vs as</p>
<p>func method(parent *a) {
}</p>
<p>The same idea for "new" methods (when you have to initialize a new struct), call it MyStruct.New(Arg) or NewMyStruct(Arg)</p>
<hr/>**评论：**<br/><br/>chewxy: <pre><p>I think a good way to think about it is to stop thinking in terms of classes. Structs are literally memory. "Methods" are syntactic sugar (which has a secondary job of interface satisfaction) :</p>
<pre><code>func (t T) funcName() {}
</code></pre>
<p>are exactly the same as:</p>
<pre><code>func funcName(t T) {}.
</code></pre>
<p>Once you start thinking of methods as just functions which has a receiver in the first arg, you'll start to see certain patterns emerge. Then apply said patterns to your work. Typically you'd want to make something a method when you want to satisfy some interface. Otherwise, they make no difference.</p></pre>nilslice: <pre><p>Typically you'll define a method on a struct receiver when you're implementing an interface, or when the behavior is specific to the struct. By writing a function that accepts a struct as an argument, you're limited to calling that function with only the one struct type, unless your function accepts an interface{} </p>
<p>Additionally, writing the method using a struct receiver is useful when embedding that struct type into another struct, which then gets to also use the methods of the embedded struct. Whereas a function written with the struct as an argument can only be used with the type defined in the function signature. </p>
<p>In your example, "MyStruct.New" is most likely referencing a package, called MyStruct, and an exported function, New, which returns a pre-initialized instance of some struct in MyStruct package.</p></pre>metamatic: <pre><p>Generally it's a question of where the functionality of the method belongs. In OO programming, you generally ask objects to do things to themselves, rather than passing objects to functions to act on.</p>
<p>However, sometimes it's arbitrary because there are at least two classes the method could logically belong to. For example, you could choose <code>database.save(object)</code>, or you could choose <code>object.saveIn(database)</code>. </p></pre>damian_is_oppresive1: <pre><p>Both are just ways of organizing a codebase. Use em how you see fit. Method receivers are just an abstraction.</p>
<pre><code>s.put(i)
put(s,i)
</code></pre>
<p>pick your poison.</p></pre>kemitche: <pre><p>As others have said, there's little difference technically. The three main reasons, in summary, to use the method-on-struct approach are:</p>
<ol>
<li>To ensure the struct (or pointers to the struct) implement a desired interface</li>
<li>As organization/namespacing (you can only have one <code>func funcName(t T)</code> in a package, but you can have a <code>func (t T) funcName()</code> and a <code>func (s S) funcName()</code>, etc.</li>
<li>Ease of use, particularly for editors with autocomplete. If I'm using a <code>T</code> class, it's easier in many cases to write <code>t.FuncName()</code> rather than <code>pkgname.FuncName(t)</code>.</li>
</ol></pre>lespritd: <pre><p>One good reason to use the method is if the function you're implementing needs to have a particular type signature and you want to use a struct as a closure.</p></pre>
