I really only use singletons for lazy initialization of things. If I have to construct a message routing window, I won't actually do so unless I must. Singleton does make that easier.
But yes, most people throw a singleton in and mistakenly think that since it is a design pattern it is somehow cleaner. Bzzt, a global is still a global by any other name.
And I prefer monostate to singleton anyway.
Am I crazy? what is a singleton?
The only argument for singletons that I can agree with is that if you make something static you can't control exactly how and when it's created (at least I've heard this argument several times).
Singletons is something that popped up in a "famous" game-programming book and everybody wanted to be cool and started to use it. As I see it singletons can make global hell a bit colder but still if you have an oo design then you're fine anyway....
Singletons is something that popped up in a "famous" game-programming book and everybody wanted to be cool and started to use it. As I see it singletons can make global hell a bit colder but still if you have an oo design then you're fine anyway....
I think antareus stated the right reason to use it: sometimes you need either 0 or 1 instances of a particular class, and always using a static Singleton.get method to access the object lets you not worry about wheteher and when it will be initialized. At least, that's all I've seen in singleton implementations - the only extra trick is to make them thread-safe; there are apparently a dozen ways to do this wrong in Java, so every Java site writes an article about how to properly use singletons. You only need to use this for objects which are expensive to instantiate and which are not used every time the program is run. For example, a connection to a database, a script interpreter, or a large lookup table.
Quote:Original post by Zahlman
- to solve static order of initialization problems. (Which, in Java at least, are a Can't Happen(TM), unless you have a cyclic dependency that would need some other resolution strategy *anyway*. C++ certainly allows the possibility though.)
Singleton's in C++ cause far more initialization problems than they solve.
Quote:
- to allow runtime polymorphism in order to select some singleton subclass to treat as "the instance" (I am told this gets used for abstracting away rendering layers when you - somehow! - don't know until runtime which graphics API you're going to use.)
Bingo! Regard cin & cout as legacy examples
Quote:Original post by Magmai Kai HolmlorQuote:Original post by Zahlman
- to solve static order of initialization problems. (Which, in Java at least, are a Can't Happen(TM), unless you have a cyclic dependency that would need some other resolution strategy *anyway*. C++ certainly allows the possibility though.)
Singleton's in C++ cause far more initialization problems than they solve.
Ironically enough, earlier today I was pondering that "now they have two problems" quote about regexes, applying it to singletons instead. :)
Quote:
- to allow runtime polymorphism in order to select some singleton subclass to treat as "the instance" (I am told this gets used for abstracting away rendering layers when you - somehow! - don't know until runtime which graphics API you're going to use.)
Bingo! Regard cin & cout as legacy examples
... Why wouldn't the program know at compile time what cin and cout are? Won't they always have the same implementation for the platform being compiled on?
Quote:Original post by ZahlmanQuote:Original post by Jingo
Singletons are not replacements for globals. The only thing they have in common is the global point of access. The singleton pattern ensures that there is only one instance of a class, a global does not do this.
I could be completely misunderstanding, but when I fill in the missing words and substitute the backreferences in "a global does not do this", I get "using a global variable does not ensure that there is only one instance of the global variable."
No, you get "using a global variable does not ensure that there is only one instance of a class".
A singleton will prevent the global being changed in the middle of your code to point to something else.
Of course you would be an idiot if you actually did this, and if your were working with someone that did then they shouldn't be there for much longer.
RenderManager *renderManager;void DoSomethingInMiddleOfGameLoop(){ //... renderManager = new RenderManager; //...}Of course you would be an idiot if you actually did this, and if your were working with someone that did then they shouldn't be there for much longer.
I know two cases where a singleton may be useful:
1) The class is part of a class hierarchy and needs to override some virtual functions. For example, it can be useful to have a "dummy" or "empty" object that does nothing. It would be a waste to create several such objects. In this case, you get the object with the Instance() function but you still pass the pointer in a bigger system that is unaware of the existance of the singleton.
2) You have only one instance right now, but you plan to have several later. In this case, the change will be smaller if the object is defined as a class in the first place.
Otherwise, a namespace with functions that "privately" access data defined in the source file (.cpp) is a much better approach I think. It separate interface and implementation even more than a class without the cost of using virtual functions (which are the way to separate those with classes)
alexk7
[Edited by - alexk7 on July 7, 2004 7:29:46 PM]
1) The class is part of a class hierarchy and needs to override some virtual functions. For example, it can be useful to have a "dummy" or "empty" object that does nothing. It would be a waste to create several such objects. In this case, you get the object with the Instance() function but you still pass the pointer in a bigger system that is unaware of the existance of the singleton.
2) You have only one instance right now, but you plan to have several later. In this case, the change will be smaller if the object is defined as a class in the first place.
Otherwise, a namespace with functions that "privately" access data defined in the source file (.cpp) is a much better approach I think. It separate interface and implementation even more than a class without the cost of using virtual functions (which are the way to separate those with classes)
alexk7
[Edited by - alexk7 on July 7, 2004 7:29:46 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
