> You misunderstood the singlenton pattern. It's not about "Managing and sharing a single instance", it's about only being able to instantiate one instance of a class.
Not quite, you're confusing a particular way a singleton is implemented with the whole purpose of a singleton and why there's a need to restrict a class to have a single instance to begin with.
To illustrate your misconception, you can instantiate a regular class as a global variable and specify that no other instance is allowed in a project in the project's coding standards to enforce this at the code review level, and you still have a singleton.
The whole point of a singleton is that only one instance of a class is used across the system, regardless of whether this is enforced by any technice or not.
Don't confuse a specific implementation with the purpose, and requiring/expectinv only one instance of a class to be available is obviously not an anti-pattern.
> ...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.
> Not quite, you're confusing a particular way a singleton is implemented with the whole purpose of a singleton and why there's a need to restrict a class to have a single instance to begin with.
Have you actually read the definition(s) of the singleton pattern? E.g. Wikipedia: "In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one "single" instance." (https://en.wikipedia.org/wiki/Singleton_pattern)
And it's the same in most other definitions.
Also, make sure to read the criticism on the Wikipedia page - I think the criticism there is enough to classify it as an antipattern, because again, it's not about just having one instance of a type/class.
> Have you actually read the definition(s) of the singleton pattern? E.g. Wikipedia: "In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one "single" instance."
Yes, I did. I also know what a singleton is, and the whole point it's a thing. Did you read my explanation were I pointed out your misconceptions?
> Also, make sure to read the criticism on the Wikipedia page - I think the criticism there is enough to classify it as an antipattern,
You should first take your own advice into consideration and first read your sources before citing them. If you did before succumbing to your appeal to authority, you would have noticed the fact that your whole argument that singletons supposedly were an anti-pattern is what, and I quote, "it is frequently used in scenarios where it is not beneficial" because of the global state. Do you understand the problem with the way you're trying to generalize an assertion, specially given that enforcing a global state is often the whole point of using a singleton? If you fail to understand how/why/when a technique is used, that does not make it an anti-pattern.
Lastly, please get acquainted with HN's guidelines on commenting as your last comment goes against a few principles stated in them.
We are talking about design patterns here, about the singleton design pattern. And not just about singleton objects. You still seem to mix up the two things.
> Lastly, please get acquainted with HN's guidelines on commenting as your last comment goes against a few principles stated in them.
I think you are just misunderstanding me (and the OP) and I'm trying to clarify. I don't see which principle I would violate with that.
> We are talking about design patterns here, about the singleton design pattern.
I appreciate your attempt to move the goal post and gaslight, but it's already readily apparent that you're very confident in your misunderstanding and misconceptions, and very resilient to their clarifications and corrections. You're free to learn about the basics of design patterns if you'd like but until then I see no point in continuing this discussion.
Not quite, you're confusing a particular way a singleton is implemented with the whole purpose of a singleton and why there's a need to restrict a class to have a single instance to begin with.
To illustrate your misconception, you can instantiate a regular class as a global variable and specify that no other instance is allowed in a project in the project's coding standards to enforce this at the code review level, and you still have a singleton.
The whole point of a singleton is that only one instance of a class is used across the system, regardless of whether this is enforced by any technice or not.
Don't confuse a specific implementation with the purpose, and requiring/expectinv only one instance of a class to be available is obviously not an anti-pattern.