Interface Pattern Encapsulating both In-Memory and Network Data Storage

<p>hi everybody. i&#39;m relatively new to golang, and still trying to get accustomed to the idiomatic way of doing things with it. suppose you have an application that relies on word count data, which could either come from an in-memory implementation or a remote key-value store. instinctively, i want to abstract the in-memory vs. network implementation behind an interface like</p> <pre><code> type WordCounter interface { Increment(string) GetCount(string) int } </code></pre> <p>however, because golang treats errors as values, the networky implementation of the <code>WordCounter</code> interface would have to return errors in addition to whatever else the interface methods would return. one possible solution is an interface like...</p> <pre><code> type WordCounter interface { Increment(string) error GetCount(string) (int, error) } </code></pre> <p>with the in-memory implementation always returning nil for the error fields. this works, but it feels very hacky. i was wondering if anyone had any patterns they liked for this sort of situation. thanks!</p> <hr/>**评论：**<br/><br/>djherbis: <pre><p>I don&#39;t see anything wrong with having error always be nil for the in memory implementation.</p> <p>This is what happens with bytes.Buffer: </p> <p><a href="https://golang.org/pkg/bytes/#Buffer.Write" rel="nofollow">https://golang.org/pkg/bytes/#Buffer.Write</a></p></pre>vroomwaddle: <pre><p>well, if it&#39;s good enough for the standard library, it&#39;s good enough for me. thanks!</p></pre>TheMerovius: <pre><p>Just think about the alternative in your favorite, exception-based language: Your implementation would in one case throw nothing and in the other case throw an IOException of some kind. You still need to decide in the user of your interface whether you want to catch an exception or not.</p> <p>Or with algebraic datatypes: As one implementation might fail, you need to put a Maybe&lt;int&gt; as the return value and unpack it anyway.</p> <p>So, fundamentally, nothing changes by the way go handles errors, except a little syntax (e.g. if err != nil instead of try{…} catch e{ … }). So, no, this is not a hack, this is simply the way every language does it and go isn&#39;t special :)</p></pre>egonelbre: <pre><p>You are looking for an idiom, not a <a href="https://en.wikipedia.org/wiki/Pattern_(architecture" rel="nofollow">pattern</a>). <a href="http://stackoverflow.com/questions/12981021/are-there-any-patterns-in-gof/24664544#24664544" rel="nofollow">Patterns</a> have important attributes that make them &#34;patterns&#34;.</p> <p>The interface doesn&#39;t really make sense, it looks too fine grained:</p> <pre><code>package word type Count struct { Word string Count int } type Table interface { Collate(counts []Count) error // alternatively: Collate(counts map[string]int) error CountsFor(words []string) ([]Count, error) } </code></pre> <p>This would also get rid of some error handling code and work better on network.</p></pre>