(quick note, consider XP to mean any test driven practice. I didn't clearly
express that and would rather not try to get it right in every circumstance)
Not particularly. However, you did note that these folks "may or may not
know what they are talking about". In my mind, you were implying that
their
opinion was not useful because you were not aware of any potential
credentials that may lend them credibility. Maybe I misunderstood your
statement. I was only attempting to point out that this objection was
perhaps inconsistent with the content of the specific page.
Well, for one thing, if the name isn't well known, the credibility is pretty
much non-existant to start with.
Secondly, the more pressing point is that the arguments themselves don't
lend the authors credibility. A big name may sway some people, but its not a
particular good situation when your argument requires your name to hold any
weight.
Anyway, we've agreed that the wiki itself was weak.
On to the other stuff.
I agree that common practices need to built on general consensus. The
patterns community largely has reached consensus that the Singleton
pattern
is often misused and should be described with sufficient cautions and
warnings to help new readers to avoid common mistakes. You do not need to
take my word on it. Perhaps some of the links I provided will help. You
can also google on the term "Singletons Are Evil" to find more.
In reading these articles, I see a common thread within them. That is most
every person is an XP\Unit testing fan with certain expectations. That is
far from a singluar consenus. That is a small community trying to dictate
what the larger community should do. Some of the constituent ideas are good,
but that doesn't nessecerily mean that the particular communities ideas
inherently are. The argument against singletons outside of unit testing
environments takes a considerable blow
I don't know whether to respond to this or not. I don't consider it
harmful
for an author to warn their readers away from a practice that they feel
will
produce code that is difficult to debug or maintain. Whether or not you
agree with their evaluation of the "offending" practice, we all benefit
from
the discussion.
I don't feel its harmful is the purpose of the author was to discuss
potential problems. It, however, is when the author is writing a strictly
technical piece. An article that discusses *how* to write a singleton
correctly is not the proper place to discuss whether singletons are good
practice or not. That is the arena of an opinion piece, not a factual
document. Including such opinions in the context of a technical discussion
will either take merit from the techincal article itself or give false merit
to the opinion. It is potentially unethical, at least to my mind.
Your statement is no more or less "opinion" than those of the people whom
you label "purists." The statement that "nothing is bad" is as much a
valid viewpoint as the statement that "globals are bad" or that
"Singletons
are commonly misused." In that same vein, to leave a potentially harmful
practice without a warning is making a statement of opinion just as much
as
placing a warning. It is an act of omission. It is still the expression
of
an opinion. Ultimately, it is the opinion of the author that always
emerges, and it is the judgement of the reader to accept or reject that
opinion.
Of course, it is certainly opinion. The more pressing issue, however, is
that I didn't include it in a discussion about how to declare global
variables. Omitting negating opinions is not nessecerily a show of opinion
when the context of the ommission is a situation where the opinion does not
belong.
Every one has opinions and everyone expresses them constantly. Even within
this newsgroup, there are times when i'll reply factually to a question and
then express an opinion along side it. I take extra care to try to seperate
the two into distinct units, but it is not always possible. However, I try
to only express opinoin in an instance of something being done incorrectly,
say someone using a singleton ArrayList(contrived, I know) to perform
sorts.I would strongly suggest a different approach. However, I would not
suggest abandoning singletons if the user wasn't using them in an egregious
manner.
Within the newsgroups, mailing lists, forums, etc we are free to do that
because we can tailor our opinions to the exact situation at hand and choose
only to express them when the situations demands it. Within an article which
is not focused on a given usage of a pattern, but strictly on the technical
information required to get the pattern right on a given platform you cannot
do that and you risk giving confusing or downright incorrect advice. In that
situation you are telling everyone that they are probably wrong, no matter
what their usage is, which isn't what they came looking for.
Again, pointing to a (balanced) best practices document or FAQ on the
subject without an explicit "don't use this" is an entirely different
matter. That allows the author to explain the issues without having to muck
with the techincal issues themselves.
It is kind of silly to warn people not to use a hair dryer while sitting
in
the bathtub. However, people have done that, and injuries have occurred.
A
warning is usually justified if even a small number of poorly educated
people do something that more educated people would scoff at. In
programming, we are not dealing with life and death quite so much, but
that
doesn't mean we shouldn't consider using a similar standard.
And I have no problem with that standard. When you are dealing with
pointers, warning that arithmetic errors may cause the application to crash
or behave strangly is one thing, but warning that using a singleton may just
aggervate someone who holds an opinion on singletons is quite another(in my
opinion, the singleton issue is only going to be an issue if some
circumstances are met. It will likely not be an implicit one that is going
to occur in every situation).
Can we move from a discussion of the wiki article itself to a discussion
of
Singletons, please? I concede that the wiki article was not a good way to
introduce readers to a discussion that was VERY visible and very heated
just
a few years ago. I thought I was reminding folks. I should have been
more
careful in respect to people who had missed the earlier discussion
completely.
Discussion of a singleton itself is slightly off topic at this point, I
think. However, I did read through the articles and I saw a few fundamental
flaws:
1) Many of the arguments given are entirely predicated on XP, which is a
terrible way to declare a practice. XP simply is not used widely enough to
consider a problem with XP to be a problem with programming as a whole.
Issues with singletons and XP are the domain of XP and XP articles, not
singletons and singleton articles.
2) The discussion of not knowing what a class is using based on the
signatures is empty minded, to say the least. Classes are entirely capable
of instantiaing objects or performing mischevious casts and other behaviour
to locate quite a bit of information you cannot or will not realize you are
passing in. If you can't see the code you simply cannot know for sure what
the application is actually doing or acting on, period.
3) No argument I've seen yet offers a real solution, just high-handed advice
to redesign your class so it fits a non-singleton design so that you can use
unit testing better. Why not simply redesign your Singleton so that unit
testing is easier instead? Clairty of code is paramount, additional
parameters and deeper callstacks plus additional threading and message
passing to maintain interoperation between instances does not clarify code,
it obfusticates it.
4) The entire concept is highly stooped in OO. OO is not the perfect
paradigm and singletons allow designs to slightly exceed OO's restrictions.
Forcing everything into an OO purist POV is only good for OO purists. For
everyone else it is a hassle they don't want to deal with.
My final thoughts on the negative sides is that these particular users
should switch to entirely functional languages; they will probably be
happier without state of any kind.
Now, for the good points,
1) Careless use of singletons can result in a design that will not scale
across appdomains or complicated component designs and will certainly be a
cause for concern if your application may need to scale up and out at some
point.
2) Many uses of singletons are badly thought out. While configuration is one
I'm not entirely sure of(Trying to create a real linkup between
configuration instance independence and uniform configuration state without
a singleton or non-literal equivilent is a real mess, I've tried it), many
of the other ideas mentioned may well be badly designed.
3) Avoiding singletons(literal static ones and a single instance floating
all over the place) can free your code from locking and other threading
issues. That is a significant simpliciation in its own right.
4) Emphasising factories instead of generic static singletons is a good
idea. The trouble is how to locate factories and how to avoid turning
factories into singleton machines, but that is well beyond the scope of this
discussion.
For the good side, there are certainly good arguments, just not nessecerily
enough to entirely drop the pattern. I do see potential flexibility issues
with singletons and prefer to use service providers when possible, there
simply isnt' any kind of infrastructure available to avoid the use of
singletons without going to extreme ends to provide rarely used
functionality within a component architecture(such as dynamic component to
component discovery and communication). I'm left wondering which is worse, a
tough to test singleton or an easy to test but mostly unnessecery cross
service communication system.
But then that too is well out of the scope of this post. I'd probably have
to spend several hours designing and considering such a system before I
could say which way my mind would end up.
.