Re: Singletons
On 12/12/2012 7:25 AM, Dave Abrahams wrote:
on Mon Dec 10 2012, Balog Pal <pasa-AT-lib.hu> wrote:
On 12/2/2012 4:04 AM, Dave Abrahams wrote:
Disagreed. The problem is not that it's hard to fit in. The problem is
that it locks the client code into using that globally unique object, so
it can't run in other contexts (e.g. in a testing context with a mock
playing the role of the unique object???see
http://www.androidsx.com/cant-test-that-singleton-try-dependency-injection/).
Anti-pattern.
I see this claim being repeated almost as much as the lie that 'java has
no pointers'. I just can't get what is the problem mocking a global
accessor function in a test environment or providing it in another
application.
When you try to decrease your testing turnaround time by running your
tests in multiple threads, I think you'll discover the problem pretty
quickly.
Look, just like strange women lying in ponds, distributing swords --
careless test practices are hardly a good basis for application design.
Threading is not something you can just throw at a codebase that was
thinking a single thread and expect any good. While if it was
thread-aware, surely functions are classified as 'thread-safe',
'main-thread-obnly', 'need mutexing' and similar categories the caller
must heed. The tester included.
On the bright side you probably still can parallelize the test suite
launching a process per core executing different part of the suite.
Dependency injection is one tool to do things,
Yes
but it's hardly an only way.
I never said otherwise. However, the better writings about DI do make
the problems with singletons and global state quite clear.
IMO singletons are pretty old, and whoever is not aware of their
consequences clearly shall have his check-in rights suspended. :)
And being better versed in all alternatives is good, but shall never
lead to religionism, trendism or hasty judgements.
And it is definitely not without a huge cost, comparable to the one it
suggests to eliminate.
Huge or not, as I mentioned elsewhere, it's a short-term cost for
long-term gain.
In some situations. And the opposite in others. You can't tell without
looking. And definitely shouldn't even try. Would you expect a doctor
provide diagnosis or therapy over the phone never doing actual
examination? In many places that could put him in jail or set beack by
serious amount of money. Our field should converge that approach.
The arguments for it are similar to those opposing exceptions and trying
to force the old-style return-code-football.
Interesting you should make that comparison. I have a pretty clear
record since 1996 of puncturing rampant exception FUD (just search this
newsgroup),
I don't need to. I closely follow your activity for some 15 years in
forums, boost, wg21. And you're on the short list of people I regularly
make references on seminars, not limited to the the Abrahams exception
guarantees.
So your initial post in ths thread left me pretty much baffled.
but you think in this case I've bought into something
equivalent?
Yes I do. So please do us a favor and reread your posts, and let's start
some actually technical discussion, whith some fair conclusions.
I don't think so. Globals hurt modularity, flexibility,
and reusability, mutable globals hurt parallelizability,
Please help me decypher this statement. Do you imply the first three
stand for const globals?
and wrapping an
"accessor function" around a global does precious little to change any
of that.
In the meantime, let's follow the last statement, made on mutable
globals. Taken literally I certainly agree with it. But it is not a good
one, my improved version would start as
"Shared mutable state" hurt pralallezability.....
Now, mutable globals are certainly a case of this, but let's look at the
alternative. I create an object as local in main() and create a few
hundred copies of its address in params or class member variables --
does it make it any less shared?
Just like wrapping it in a global function, PFA-ing helps about as
little. AAMOF it even prevents some tricks usable for a few practical
cases (like the global function returns proxy to the object that is locked).
In practice I see it typical that singletons are either fully
thread-safe (doing internal short-time locking) or have the 'main/GUI
thread only' label. What is not hard at all to review and keep that way.
There PFA helps nothing thread safety-wise, while I can draw
situations where it could hurt reviewability.
Especially if you use the singleton naturally as I suggested earlier,
being an object, not a class. With the DI/PFA method you create
aliasing. Opening that can of worms.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]