Re: Singletons
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.
Dependency injection is one tool to do things, but it's hardly an only
way. And it is definitely not without a huge cost, comparable to the
one it suggests to eliminate.
The arguments for it are similar to those opposing exceptions and trying
to force the old-style return-code-football.
Please, everyone, before arguing for Singleton, take some time to
research the arguments against it and understand how Dependency
Injection addresses those issues.
Guess those who actually did the comparison are wide aware that you CAN
refactor any program between the two states. Some might even did it in
practice, and tasted the difference. It is quite showing when you have
the first phase diff of a dozen lines and the rest induces thousands, to
connect the ends. And then find a ton of functions and classes get their
original well minded (hopefully single) purpose watered up to join
postman duties.
I didn't even mention the impact on a system that HAS logical constness
in mind. No wonder I see most proponents of DI use java examples where
it was discarded up front.
Or the maitainance after the first effort. Ok, you finally get rid of
the app's global Logger singleton and instead of the few spots that must
emit log records just do so, half the system is passing a Logger
reference. Tomorrow you get a simple change request, that in part wants
a new place to log instead of an old one. again, instead of a few lines,
you have to build a passing track to the new place. And demolish to now
obsolete one to the old. Or chose to keep it in place, serving no useful
purpose -- make it tomorrow's maintainers problem to figure out why the
parasites are there.
It may in fact be that there are good
reasons to use Singleton even in the face of those arguments, but I hope
at least we can avoid rehashing questions that have already been
compellingly decided.
Yes, there is a bunch of good reasons NOT use singletons, and we can see
many systems that disregard them. What I see lately extrapolated to this
singleton-as-antipattern nonsense. That in practice leads to more bad
design trying to pick up trends and emotionally suggested stuff instead
of actual thinking and understanding the alternatives.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]