Singleton pattern for a client handle

[krma...@gmail.com]

I want a single instance of a client handle to be initialized.

Is it ok to declare the instance as

var client MetricsClient

and then initialize it using sync.Once().

Is it required for some reason that the client be a pointer  or are there are other issues with it. My requirement is to be able to initialize that handle just once 

[awickert]

You can implement a singelton similar to Java. A paper [0] has already solved the problem in 2010. Simply take a look at section 3.1.

[0] http://www.doc.ic.ac.uk/~ncameron/papers/schmager_plateau10.pdf

 

[Shy Robbiani]

If you really need this, Svett Ralchev provides a nice example using sync.Once() in his blog:

http://blog.ralch.com/tutorial/design-patterns/golang-singleton/

[Ian Davis]

The solution presented in the paper is racy and it would be quite possible to get two copies of the registry. Better to use sync.Once to initialise it.

 

-- Ian

 

[Ian Davis]

[Val]

Indeed.
I find it weird that the authors care more about lazy init (not strictly required for singletons) than about ensuring properly that multiple instanciation cannot happen.

[Nathan Fisher]

I often put all of my wire-up in main which ensures that it's only one instance. Then I create a struct that all of the dependencies hang off of like loggers and clients.

On Thu, 30 Jun 2016 at 23:30, Val <dele...@gmail.com> wrote:

Indeed.
I find it weird that the authors care more about lazy init (not strictly required for singletons) than about ensuring properly that multiple instanciation cannot happen.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[krma...@gmail.com]

does the singleton variable for any reason need to be a pointer ?

[Nathan Fisher]

Methods; specifically pointer receivers. Using a value will create copies of the struct on every method call whereas pointers will use the same struct.

Another benefit is to optionally do an atomic swap or use a mutex guard if you wanted to change the instance at runtime (eg config reloads).

Personally I've come to the realisation that the singleton pattern is one of the worst design patterns. I abused it a lot early in my career because of its short-term convenience factor. However in OO terms it fails SOLID. In testing terms it's a PITA to work with as it requires that all tests run serially and have a "setup" or "teardown" that ensures the singular instance is reset to a well known state.

Better to use a factory method and have the class package local/private (which isn't great practice). Even then I still feel it's a bad pattern because it becomes very complex to stub out and doesn't make dependencies explicit.