Re: Creating framework for singleton pattern?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: 10/23/04 

Date: Sat, 23 Oct 2004 00:07:25 -0500

(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)
>>
>> That is supposed to be impressive, then?
>
> 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.

>
>> Common practices need to be built on a general consenus, which I have not
> yet seen.
>>
>
> 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 particularly like the "NEVER USE GLOBAL VARIABLES OR
>> ELSE" threats issued in best practices books and articles. They are
>> inflammatory and without regard for reasons to use global variables and
>> patterns beyond the OO purists point of view. OO simply isn't everything
> and
>> shouldn't(perhaps cannot) be shoehorned into every solution. The mere
>> fact
>> people use singletons and static members is a testimony to that.
>
> 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.

>>
>> Best practices are best only in the sense that they are ideal. Ideality
> and
>> the real world don't always coincide. Global variables are fine when they
>> are appropriate, as are singletons and gotos. No one of them should be
>> labelled as bad, just particular patterns using them.
>
> 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.

>> I simply
>> replied that you hadn't offered much in way of suggesting that this is a
>> warning thats anymore valid than say...a warning that the household
> cleaner
>> may smell bad. It may be true, but it may not really be a useful one. A
>> warning is certainly merited if there are real problems, but it is not if
> it
>> is based entirely on a small selection of people and their particular
>> view
>> on the world.
>>
>
> 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).

>
>>
>> Yes, anyone can investigate further, they say that with regards to alot
>> of
>> things(like commercials, for example), but what percentage does? Much in
> the
>> same way as it would be to mention no negatives at all, it is rather
>> unbalanced to only reference negative ideas about a given idea in an
>> article(even if that articles entire purpose is to discredit or
>> discourage
>> an idea). An article that only points out the flaws in something or goes
> out
>> of its way to make a point in exposing flaws is particularly
> untrustworthy,
>> or should be considered as such, IMHO.
>
> 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.

Relevant Pages

  • Re: Creating framework for singleton pattern?
    ... > Opinion is the name of the game, and, IMHO, previously insufficent ... > was presented to base an article warning off of. ... I agree that the wiki page was, by itself, insufficient to make an argument. ... > people use singletons and static members is a testimony to that. ...
    (microsoft.public.dotnet.languages.csharp)
  • Singletons
    ... What would in your opinion be the justified case for singletons? ... I have seen code which relies far too heavily on singletons and this cannot bring anything good. ... I'm somewhat on the other extreme - I'm not sure at all if singleton is good idea in any situation. ...
    (comp.object)