Re: StateFull vs Stateless Singleton
On Jul 5, 2:36 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
On 5 juuli, 05:48, sebastian <sebastianga...@gmail.com> wrote:
[...]
Why the problem with singletons is not so apparent? What is
the difference between calling "globalVariable.doSomething()"
and "SingletonClass::instance().doSomething()" (other than
some extra letters to type on second case)? Both are tight
coupling with global state only semantics are different.
Sometimes it is not worth to avoid tight coupling between
close classes but singleton is far and global.
The problem is not only tight coupling between distant things
but that such coupling is hidden within code (call site).
One often named purpose of singletons is that these limit the
count of how many instances there may be simultaneously (1 on
case of singleton). That sounds like responsibility of owners
of objects to limit number of simultaneous instances. Oh yes,
global state does not have owners, it is self-owned.
Also why only one instance? Who knows. "Pragmatic" reasons
like "There was only one
window/database/display/player/client/user/account/store/
harddrive/configuration when we started with that application,
so we decided to carve it into rock in most hard way to
modify." Mono-media.
I think there is some confusion about what is meant by
a singleton. A singleton is a class which can only be
instantiated once, regardless of how it is implemented. In C++,
the most frequently cited idiom handles order of
initialization (and is incredibly verbose), but that's
a secondary aspect.
Secondly, if the fact that a class can only have one instance is
a fundamental invariant of the class, it makes more sense for
the class itself to ensure this than for it to count on the
client not making mistakes.
Finally, the amount of coupling is to a large degree independant
of whether something is a singleton or not. Arguably, there's
even more coupling if you're passing a pointer to Log into every
function in the application. And in my experience, most
singletons are either static members, or are found in an unnamed
namespace.
In the end, the only real arguments against singletons are that
1) they are often abused (but then, so are a lot of other
things), and 2) the usual syntax is excessively verbose (but
that's easy to fix---just use a lighter syntax).
--
James Kanze