<p>I'm writing a library for the first time and I think I did something wrong in exposing the functions. Right now it behaves like so:</p>
<pre><code>import (
"mylib"
)
func main() {
mixer := mylib.NewMixer("ingredients")
mixed := mylib.MixThing("data", mixer)
unmixed := mylib.UnMix(mixed, mixer)
}
</code></pre>
<p>But should it behave more like:</p>
<pre><code>func main() {
mixer := mylib.NewMixer("ingredients")
mixed := mixer.Mix("data")
unmixed := mixer.Unmix(mixed)
}
</code></pre>
<p>or:</p>
<pre><code>func main() {
mixer := &mylib.NewMixer{Ingredients: "ingredients"}
mixed := mixer.Mix("data")
unmixed := mixer.Unmix(mixed)
}
</code></pre>
<p>Or something else? Or does it matter?</p>
<p>Sorry if the question is unclear or stupid. </p>
<hr/>**评论：**<br/><br/>daveddev: <pre><p>A "new" function keeps the surface of the API clean, and provides a place for validation of any configuration/dependencies.</p>
<p>Regarding using methods or package level functions, the semantics of the second example seem more correct. Package level functions tend to be utilities/helper functions that operate on common types while methods are the force behind a type's structure (unless the type is acting more like a basic storage type).</p>
<p>I'm sure this could could have been explained better, but I hope it helps.</p></pre>JokerSp3: <pre><p>If your mixer requires any work to construct then the New pattern is your best bet. If your struct has defaults and can handle being constructed without any other work (or has no private fields) then keeping it simple (mixer := mylib.Mixer{}) is really nice.</p>
<p>The decision to make Mix a method or a top level function depends on how it is used. If it is a function working off a mixer and requires the mixer state then make it a method. If you will ever have a different kind of mixer or you don't require the mixer make it top level function.</p></pre>driusan: <pre><p>I'm not really sure what you're trying to do (especially since all of the examples would be compile errors due to unused variables..)</p>
<p>That said, 2 looks the best to me. 3 would be okay, except I don't think your struct type should have "New" in the name.</p>
<p>And for all of them, why not just "mixer.Unmix()"?</p></pre>daveddev: <pre><blockquote>
<p>And for all of them, why not just "mixer.Unmix()"?</p>
</blockquote>
<p>mixer.Unmix() (no args) likely does not hold the required dependencies, at least not obviously. This emphasizes the nature of the question for me. It's not as general of a question as I first took it to be; It seems to be about how OO the API should be, if at all. In that line of thinking another possibility is to call mixed.Unmix()</p>
<p>... My current thought is that any answer to this question, as it is now, would be assuming too much about the rest of the package (it's intent, scope, etc.). Flesh it out and use it. See what's comfortable as it comes to light.</p></pre>driusan: <pre><p>Oh, you're right.. I misread that as the same variable name passed multiple times. If anything, it should be mixed.Unmix()...</p>
<p>Side note: this is why you should try and make your variable names vary by more than 1 character..</p></pre>
