The big issue with singleton is that every time you have one db connection, one cache store, one file store, one of anything, you wind up needing a second one.
Make it easy to use the default one, but also make it easy to swap it out and use a different one.
And by that moment it is not a singleton any more. The other way around is also true, you design your system to be scalable in db, cache store, etc. and you end using only one.
> And by that moment it is not a singleton any more.
That's the point. If it's originally a singleton and you need a second instance, you're going to have a hard time. If it's a regular factory/object and you only ever use a single instance, chances are nothing will care (much, it may let some concurrency bugs or global state creep in)
>Something which I've come to believe does not exist, the pattern itself is broken.
>Paraphrasing Mencken, for every complex problem there is an answer that is clear, simple, and wrong. Singleton is ever that answer.
Just because you haven't found a good use it doesn't mean it doesn't exist. And about Mencken... All he said is that you can't have Singletons without having a Global State (obvious) and apparently he has an strong allergy to global states.
Global states are fine. Sure, they will make your tests harder but there are a lot of software that don't use unit test for legitimate reasons and hence don't have that problem.
>"One of these things is a problem you need to fix the other is a solution to a problem you don't have."
That's true, but there are so many cases were a singleton is way more convenient than the alternatives, and not using it because it might "potentially" need to scale but never does sounds a bit silly to me.
I am agreed though that you must be clear on the specifications, if a shadow of doubt appears is very to play it safe.
Make it easy to use the default one, but also make it easy to swap it out and use a different one.