Re: [ALACPP] Singleton clarification

[Christopher Smith <x@xxxxxxxx>]

On Wed, 2003-06-18 at 14:31, Jon Stewart wrote:
> I dunno'. I tend to prefer that all my methods simply have void arguments,
> and use singletons to get at non-member data. 

Sure, it's always nice, but in a lot of cases people use singleton's
when they should be passing things as parameters, or making them member
objects, or providing a more sophisticated mechanisms.

> objects that had normal value semantics. Nevertheless, one of its key 
> features is the configuration file, which can determine at run-time which 
> log statements, well, log, and which don't. In that case, your simplified 
> category objects still need to consult a central authority; that seems to 
> me like a good example of when to use a singleton.

So, I tend to have two problems with singletons, and this case is
actually a decent example of those problems:

1) The "only one instance" notion almost always needs to be qualified,
and people tend to forget to do that. So, perhaps you have it's
one-per-object, one-per-thread, one-per-process, one-per-network
interface, one-per-system, one-per-subnet, etc.

2) Singletons tend to make refactoring a tad difficult, because they
dramatically effect how navigation is done to the singleton. People
rarely use wrapper methods, so it's all short-circuited directly to a
static "getInstance()" method. So, if you have to refactor so that
access is contextual, it tends to be a significant pain.

So, one of the central tenants of log4cpp is that you have this global
configuration and namespace which governs all the logging in a given
process (so it's "one-per process"). There are neat little advantages to
this, such as being able to turn on logging in a log4cpp-enabled DLL
without having to compile it from source. However, as always, there are
cases where this is actually not the desired effect. A simple example
would be for something like an application server, where you might have
multiple instances deployed within a given process, and you may want to
have different logging configurations for each instance. Maybe you want
to avoid extreme lock contention by having multiple logging sinks. You
can try to hack around this using instance-based category names, but of
course this will all fall apart if you are against using these 3rd party
DLL's. Correcting this problem is non-trivial as much of log4cpp assumes
the root category is a singleton.

If instead, getInstance() took a reference to the root category, and the
system allowed for multiple roots, it'd be much more natural.

> You can always get around using a singleton, but it can become a bit of 
> pain.

I find it's much easier to "prevent" singletons than "correct" them. So,
I try to think really hard before putting one in to a system.

--Chris
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp