Re: Confused about a thread-safe singleton example.
On Dec 3, 6:12 pm, Noah Roberts <u...@example.net> wrote:
Alan Johnson wrote:
anon wrote:
jason.cipri...@gmail.com wrote:
On Dec 3, 1:47 am, Alan Johnson <aw...@yahoo.com> wrote:
[lots of cutting]
1. Don't use singletons. Ever. Pretty much all of the
value of the GoF Design Patterns book is negated by the
fact that they chose to legitimize Singleton as a design
pattern. Singleton is just a fancy name for global
variable. We should call it the Global Variable
(anti)Pattern.
greatly simplifies a lot of application code. And you are
correct, in this case it basically is, in fact, a global
variable.
Both of you are not correct. The singleton is not a global
variable.
TheClass* instance = NULL; TheClass * GetInstance() { if (
NULL == instance ) { instance = new TheClass; } return
instance; }
In this case, the instance is created when the function
GetInstance() gets called the first time, while global
variables gets created before entering main()
That still has all the negative effects of a global
variable. To name a few
= hidden dependencies in functions that use it
= persistent global state
- tight coupling between anything that uses it
Explain why these are problems.
Well, they are problems. Whether they're big problems, or just
minor ones, depends on the class. And of course, the
alternative solutions aren't necessarily without problems
either. So you make a trade off---for things like the command
line, configuration files, logging, etc.---I (and from what I've
seen, I'm far from alone) find that the costs involved in using
a singleton are far less than those involved in any of the
proposed alternatives. So singleton it is.
Where are the *hidden* dependencies?
Come now... You call a function, and it changes global state.
Or doesn't---who knows?
If persistent global state is needed then why enforce a policy
that dictates you don't have persistent global state? How are
you to remove coupling between objects that use each other? Is
there some extra form of coupling you think exists here?
If the coupling is there, you can't remove it---if an object
uses configuration data, or the log, it depends on the
configuration data or the log. The argument is, I think, that
when these are global variables (or singletons), this coupling
isn't visible. Passing the configuration and the log to it
makes the dependency visible. Of course, it also makes for a
lot of extra work, and the people I've worked with have always
been able to understand that the semantics of configuration data
and logs are such that everything does implicitly depend on
them, so making the dependency more visible wasn't considered
worth the effort.
[...]
- typically unable to derive from the singleton class
(without heroic effort)
Who says?
More to the point: if there's only one instance of a type,
what's the point of deriving from that type?
You would typically be better off just declaring a global
variable and using that instead.
Once again, this does not protect against the creation of
another variable of that type.
Nor does it handle order of initialization issues (but that is,
I admit, secondary to the consideration you mentionned).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34