Do we really need the Singleton design pattern in Go?

<p>So today I saw <a href="http://blog.ralch.com/tutorial/design-patterns/golang-singleton/" rel="nofollow">Design Patterns in Golang: Singleton</a> trending in the <a href="https://www.linkedin.com/grp/post/3712244-6094529088666550274" rel="nofollow">LinkedIn community</a>. I found the code in that article quite odd so it made me wonder a few things:</p> <ul> <li>What problems are we trying to solve with that code?</li> <li>Is this really the idiomatic Go way to solve those problems?</li> <li>Do we really need the Singleton design pattern in Go?</li> </ul> <p>The first idiomatic example of &#34;having only one instance&#34; that came to mind was the <a href="https://github.com/golang/go/blob/master/src/net/http/client.go#L81" rel="nofollow">http.DefaultClient</a> from the Go standard library. Now I am not quite sure if this is the Singleton pattern or if it solves the same problems, so I thought I&#39;d ask here.</p> <hr/>**评论：**<br/><br/>tv64738: <pre><p>Sounds like Java people are migrating.</p></pre>kurin: <pre><p>I&#39;m pretty sure that&#39;s a race condition, too.</p></pre>philosophicalhacker: <pre><p>I don&#39;t think <code>http.DefaultClient</code> is really a singleton, and I don&#39;t really know go &#34;has an opinion&#34; about the use of singletons. I do know, however, that another googler, Misko Hervey has made a pretty compelling case against singletons here: <a href="http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/" rel="nofollow">http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/</a></p></pre>blackjackjester: <pre><p>My question to him is would be &#34;why are you using mutable singletons&#34;. Maybe you don&#39;t always have control over it, but its just another example of &#34;who is responsible for bad code? The language, or the developer?&#34;</p></pre>weberc2: <pre><p>Tons of respect for Misko Hervey. He&#39;s also written <a href="http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-decided-to.html" rel="nofollow">Writing Testable Code</a>, which is the best explanation I&#39;ve found for how and why code testability is important.</p></pre>nate510: <pre><p>In my experience, Go tends to ignore the singleton pattern and (for better or worse) trust developers to understand and abide by simple conventions. </p> <p>For example, as pointed out by <a href="/u/philosophicalhacker" rel="nofollow">/u/philosophicalhacker</a>, <code>http.DefaultClient</code> is not really a singleton; it&#39;s simply an instance variable. In my program, I can at any point set <code>http.DefaultClient</code> to a client of my choosing. I would never do this, because it would be stupid. But I could.</p> <p>In my applications, I will frequently instantiate global objects for things like data access objects, loggers, etc., and I am trusting downstream developers to respect those objects and not reinstantiate/reconfigure them. I have mixed feelings about this, but in general I consider this more the <em>Go Way</em> than the singleton pattern described in the article. </p> <p>If you do use the singleton pattern, I would recommend adding an interface so that you can mock and unit test easier. </p></pre>Mteigers: <pre><p>The http.DefaultClient is kind of a singleton. </p> <p>Honestly we use singletons all over the place in our internal systems; Loggers, Environmental K/V storage; and Caches are all singletons we use all over the place. I think they definitely have their place for those one off type systems. </p> <p>Looking at popular logging implementations, things like Logrus rely heavily on and encourage the use of a singleton. </p></pre>weberc2: <pre><p>I think of DefaultClient as a convenience. Any code that does HTTP things should be <em>composed</em> (as a struct member or function argument) of an HTTP client and the top-level class can compose your object graph with the http.DefaultClient if appropriate. Your tests will likely want to use some sort of mock.</p></pre>