I think the real issue about singletons are global scope for types, not global scope for instances of these types. If you have a type that is global, which must not be instanced more than once (or zero), then you have a problem. That is, someone else can, by mistake or misunderstanding, instantiate too many of them. That is what the singleton pattern will prevent.
That said, the singleton pattern isn't the only solution, and usually not the best. It is easy to understand and use, and the lazy way out. Another solution would be to not make the type global. And one solution, as mentioned above, is to actually redesign the type so that it allows multiple instantiations anyway.
The Singleton Pattern: To be or not to be [used]?
If you have a type that is global, which must not be instanced more than once (or zero), then you have a problem
There is literally no problem that requires 'you must have only one or things blow up'. There are only broken designs that require such limitation.
I don't understand how you can completely avoid globals? I completely understand to avoid it as much as absolutely possible, but for instance a logger object. Should you really pass your logger instance to all objects in your game that might need logging? And also say for example you use a framework like GLFW for input, how would you pass on the callback without storing some info globally?
Remember that not everything has to be an object. Turning everything into an object can be very poor object-oriented design, in fact. Logging facilities are something that can be implemented perfectly well without resorting to some kind of "logger object" should you so choose.
But if you choose to build that API as an object or set of objects, then passing those objects to interfaces that require them is a perfectly valid solution and generally more desirable than making those objects global if for no other reason than it makes the dependency on the logging system explicit.
A typical argument for why singletons/globals are good or necessary is along the lines of your initial query: "without global access, I will need to pass this object to every function." The flaw in that argument is that it exists because of a deeper implementation issue: every function is coupled to that object.
i've yet to see a place where creating a singleton made sense to me, and "just using one instance" wasn't better.
it might be an issue on how to think about problems, but for me, it never ever made sense.
now i do understand why apis sometimes use the single global-to-you access-point, but even that does not need to be a singleton behind the scenes (it might be once-only for your app, but multiple times existing, say, in the os).
it might be an issue on how to think about problems, but for me, it never ever made sense.
now i do understand why apis sometimes use the single global-to-you access-point, but even that does not need to be a singleton behind the scenes (it might be once-only for your app, but multiple times existing, say, in the os).
How about we stop having this argument, because it always ends up with a bunch of perfectionist architects stating categorically no to it and a bunch of practical implementationists saying; the goal here is to write functioning code and anything that makes that happen is OK. And the two are never going to see eye to eye and this topic is boring after about the sixth time around.
The "there can only be one" approach is more than a little weird also from a modelling perspective. Object systems are typically designed to model real-world requirements: can you think of anything in the real world of which only one can ever exist?
Instances are unique (for example, all humans are subtly different from each other), but classes are never representative of only a single object (there can only be one sheep?).
Even things that we think of as solitary instances typically are not - the statue of liberty is treated as unique, but there is another one in France, and half a million small ones in gift shops.
Instances are unique (for example, all humans are subtly different from each other), but classes are never representative of only a single object (there can only be one sheep?).
Even things that we think of as solitary instances typically are not - the statue of liberty is treated as unique, but there is another one in France, and half a million small ones in gift shops.
Sometimes, when you do top-down systems engeering using a language like UML to describe the software, singletons pop out when an association between objects is found to have a multiplicity of exactly one (1) in either direction.
https://en.wikipedia...i/Class_diagram
This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance. Using the singleton pattern for the implementation ensures (through encapsulation of the "instance pointer" or whatever) that it is not possible to destroy/re-allocate the object instance during runtime.
https://en.wikipedia...i/Class_diagram
This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance. Using the singleton pattern for the implementation ensures (through encapsulation of the "instance pointer" or whatever) that it is not possible to destroy/re-allocate the object instance during runtime.
This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance.
No, it means that there's a 1 multiplicity of the object (in relation to others). That you're only referencing one object. It sometimes means that you only have one object.
It does not mean that your software cannot (and will never) deal with two.
<p><p>
No, it means that there's a 1 multiplicity of the object (in relation to others). That you're only referencing one object. It sometimes means that you only have one object.
It does not mean that your software cannot (and will never) deal with two.
[/quote]
Sorry, I do not follow at all.
"The UML representation of an association is a line with an optional arrowhead indicating the role of the object(s) in the relationship, and an optional notation at each end indicating the multiplicity of instances of that entity (the number of objects that participate in the association)."
If a car has one (1) steering wheel it does not mean that the car has an arbritary number of steering wheels, or that it sometimes has one steering wheel - it always has one steering wheel. If the produced car would have no steering wheels or 5 steering wheels, then it would probably not be the car that we were designing in the first place.
I'm not saying that the singleton pattern is for everyone, just that it solves the design problem of encapsulating a single object instance.
[quote name='trasseltass' timestamp='1352397571' post='4998948']
This means that, during run-time, the software itself would NEVER want to destroy or re-allocate this single object instance.
No, it means that there's a 1 multiplicity of the object (in relation to others). That you're only referencing one object. It sometimes means that you only have one object.
It does not mean that your software cannot (and will never) deal with two.
[/quote]
Sorry, I do not follow at all.
"The UML representation of an association is a line with an optional arrowhead indicating the role of the object(s) in the relationship, and an optional notation at each end indicating the multiplicity of instances of that entity (the number of objects that participate in the association)."
If a car has one (1) steering wheel it does not mean that the car has an arbritary number of steering wheels, or that it sometimes has one steering wheel - it always has one steering wheel. If the produced car would have no steering wheels or 5 steering wheels, then it would probably not be the car that we were designing in the first place.
I'm not saying that the singleton pattern is for everyone, just that it solves the design problem of encapsulating a single object instance.
Lots of good points made here against singleton, the way it should be. If the singleton's singleness is mere convenience, you're doing it wrong.
IMO there's only one "rule of thumb" you need to know: Everything that can be implemented without the singleton pattern, should be implemented without the singleton pattern.
IMO there's only one "rule of thumb" you need to know: Everything that can be implemented without the singleton pattern, should be implemented without the singleton pattern.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
