With no indication of why we should think such a thing should be. Singletons are sometimes useful, but they are the wrong answer to your problems more often than the right one. Even where they are a good answer to your problem a class should rarely enforce its own singletonness.
Idk. Depends entirely on what kind of code you’re writing. Singletons are extremely useful patterns for video games, for example. There should never be multiple instances of classes that handle things like game state, achievement unlocking, display/resolution managing, etc.
If they didn’t enforce their own singletonness then you’d have to always launch the game using the exact same startup routines, to ensure that only one of each ever gets instantiated. But game engines typically divide the game into something like “scenes”, which logically divide code and assets to only what’s relevant for that area of the game. When testing a specific level/area/scene, It’s extremely handy to have a singleton class exist in every scene, that acts as that startup routine, so you can start the game from any scene, and when you load in another scene through gameplay, the singleton class itself makes sure no duplicates exist, instead of having some kind of manager that keeps track of all that (which itself would also have to be a singleton, so you’d just be kicking the can down the road).
With no indication of why we should think such a thing should be. Singletons are sometimes useful, but they are the wrong answer to your problems more often than the right one. Even where they are a good answer to your problem a class should rarely enforce its own singletonness.
Idk. Depends entirely on what kind of code you’re writing. Singletons are extremely useful patterns for video games, for example. There should never be multiple instances of classes that handle things like game state, achievement unlocking, display/resolution managing, etc.
If they didn’t enforce their own singletonness then you’d have to always launch the game using the exact same startup routines, to ensure that only one of each ever gets instantiated. But game engines typically divide the game into something like “scenes”, which logically divide code and assets to only what’s relevant for that area of the game. When testing a specific level/area/scene, It’s extremely handy to have a singleton class exist in every scene, that acts as that startup routine, so you can start the game from any scene, and when you load in another scene through gameplay, the singleton class itself makes sure no duplicates exist, instead of having some kind of manager that keeps track of all that (which itself would also have to be a singleton, so you’d just be kicking the can down the road).
Please don’t make me tap the Gang of Four’s Design Patterns book
That book did immeasurable damage to the software industry