The optional singleton pattern about go-in-5-minutes

[gonzaloserrano]

Hi,

Don't you think that in general Singletons are a bad practice because they behave like global state and because that code that uses singletons are difficult to test? e.g https://storage.googleapis.com/gtb/TotT-2008-05-15.pdf

Related with this, what do you think about a dependency injection tutorial instead?

Thanks and keep up the good work!

[arschles]

@gonzaloserrano first of all, so awesome that you cited a 'testing on the toilet' paper!

anyway, I agree that in general they're a bad practice. generally I've seen this pattern applied in cases where you can also create an identical instance of the singleton if needed (e.g. for testing purposes). here's what it'd look like in a very simple logging package (this is similar to what's in the stdlib's log package):

package log

type Logger struct {}

func NewLogger() *Logger {
  return &Logger{}
}
func (l *Logger) Print(s string) {
  fmt.Println(s)
}

var singleton = NewLogger()

func Print(s string) {
  singleton.Print(s)
}

so, basically, the optional singleton pattern is for convenience, and you'd test against a *Logger. thoughts?

[gonzaloserrano]

Hi again,

In other languages (e.g PHP) singletons are global (e.g in PHP is implemented a static class). In the this case (and the go log package with the std var) this singleton is not exported so it's just accessible to the package, so i'd say it's not that harmful (although if that variable instantiation would provoke a side-effect then testing could be trickier).

Anyway i'm not a testing expert :-)

[arschles]

you nailed it, and I think alluded to a few rules of this pattern:

• the singleton variable must be private to the package
• the singleton variable instantiation should not have side effects
• the package should use an exported function or exported type to create the singleton variable

and I'd like to propose one more:

• convenience functions that operate on the singleton variable must simply operate on the type's functions

thoughts?

Sounds like a pretty good abstraction to me!

[arschles]

awesome, glad you agree. I'm going to be covering this pattern soon