Fuck singletons all my homies hate singletons.

I've never understood the hate for singletons

Singletons are just types of which you expect to only need one value. So just create that one value (or instance when we talk about OOP) and make it available to whomever needs it.

For unit testing create a mock instance and make the subject under test use that instead of the real thing.

Nothing to hate about them - but giving what is needed or a repository of that things to code that needs it is better than to tightly couple it with a singleton. Global state in general makes testing and extending code harder - in OOP land and everywhere else.

There's very rarely one singleton. It's usually zero or many.

@12bitfloat they often indicate a design flaw. There's very few situations where they make sense, such as logging.

@Oktokolo you assume you won't need it, emphasis on "assume". Dependency injection may come with some more boilerplate but its much more flexible.
A singleton will screw you up as soon as you wanna do anything with it that wasn't assumed by the devs who wrote it.

And I also dont think it makes technical sense. If you need 'only one of something', then make a static variable and be done with it.
Why is it that people make classes and then static get, create, delete functions to manage a single pointer.

I saw this earlier where a getInstance function would just create the object if it wasn't initialized yet. This lead to funny situations where, during shutdown, the object was deleted and created again because another thread was still trying to access it with getInstance

@atheist Then you're doing it wrong. 😠

@LotsOfCaffeine I don't understand ... there are a LOT of good cases for singletons. It does depend HIGHLY on the language and underlying virtual machine.

Singletons in Ruby or Python make zero sense: yes. Typical deployments don't have long running VMs and each request creates all the objects from scratch on each request. Objects are really fast in these situations.

Java/Scala/Kotlin/Clojure, however, are excellent cases for singletons because the classes persist across all incoming connections. You can do some amazing things with caching internally within the JVM without having to rely on tools like Reddis.

JVM/.NET languages are big tradeoffs. They have a higher spin-up time and larger memory footprints (although that's usually because of the massive amount of Java dependencies that get pulled in. If you minimize dependencies, you can get a very small Java footprint. The OpenHAB project is a pretty good example), but they also scale up very well without tools like Reddis.

Fuck writable singletons in a multi-threaded environment

@djsumdog literally my point 😉

Ideal solution for database connections, imho.

@djsumdog lots of good examples? Then name one please and I mean with architectural reasons.
Just cause what sounds like web back end relies on virtual machines and .net runtimes doesn't mean this isn't an architectural issue.

99% of the singletons I've encountered were just pure laziness. "I don't wanna pass this pointer around", " its easier that way"
They're just global variables with a different name attached. Call it the singleton pattern and suddenly its not a horrible design choice anymore.

@LotsOfCaffeine I think you have a too narrow view of what a Singleton is. It is a class you only expect to create one instance of. If you use dependency injection that ensures that the class is only instanced once (i.e. is shared by classes depending on it) it is still a Singleton.

@TheSilent There's a difference between a class that only "needs" one instance vs a singleton.

A singleton restricts you to only ever have one instance. I.e. it's a class that's only ever accessible through one global variable, or a few static functions that access a global variable.

In C++ you'd see a private constructor and a static function called getInstance or whatever

@LotsOfCaffeine It depends on the definition. What you're referring to is the Singleton pattern as defined by the gang of four.
In my opinion everything which only exists once in a context is a Singleton.
In terms of the Singleton pattern by the go4, I agree that dependency injection is generally preferable when you want to create Singletons.

@LotsOfCaffeine everything old eventually comes full circle, and is made new again.