> ...requiring/expectinv only one instance of a class to be available is obviously not an anti-pattern.
I'll disagree. There are very few situations where restricting class instantiation to one object both solves a problem and doesn't cause unneeded headaches.
Almost always a boring global with careful access control is better. It provides a single object just as well without limiting options for future software engineering needs: testing, adding construction parameters, migration, gradual deprecation, etc.
As to legitimate uses, anything with system scope can't be controlled within a process. And there are few things that inherently couldn't be instantiated twice that aren't better managed by the OS.
I'll disagree. There are very few situations where restricting class instantiation to one object both solves a problem and doesn't cause unneeded headaches.
Almost always a boring global with careful access control is better. It provides a single object just as well without limiting options for future software engineering needs: testing, adding construction parameters, migration, gradual deprecation, etc.
As to legitimate uses, anything with system scope can't be controlled within a process. And there are few things that inherently couldn't be instantiated twice that aren't better managed by the OS.