Donnie Hale wrote:
> Paulo,
>
> I've seen you mention a couple of times that you consider singletons
> dangerous. Would you care to elaborate? Is it because you're concerned that
> people can't write thread-safe code correctly? Or because correct
> thread-safe code affects concurrency? Or something else?
>
I will jump in here with a few comments.
From the Avalon perspective, where we truly value Inversion of Control (i.e.
all resources are managed by their parent), singletons that are created by
a static method on a utility class are a violation of IOC. This is especially
true when you want to hide the manager from the implementation. Many times,
all you need is a little more thought, and some minor modifications, the
parent and the child can be decoupled.
There are a number of methods of creating singletons that don't require static
methods. One of the ways we accomplish this in the Avalon world, is by
componentizing a safe interface that other components can access, and passing
the interface to the children. Most books on Components agree that there are
two essential elements: the interface is purely an interface, and the
implementation is managed by a container of some sort. Anything else is not
a Component by textbook definitions. The Interface and the Implementation also
must be completely separate entities (that is why a URL will never be concidered
a Component).
As an example, Cocoon *used* to pass a reference to itself in this manner:
interface Processor {
void process( Environment env, String uri );
}
The parent container (servlet in this case) would instantiate the Container, and
pass a reference to Cocoon as a Processor. Now, that idea has been rethought,
and it is no longer necessary to pass the Cocoon object to the rest of the system.
In either case, there is only one Cocoon object in the entire system.
If the Container can guarantee only one instance will be made, you have a singleton.
Many times that is enough. By forcing access through static methods on a class,
you not only break IOC, but you open yourselves to a broader attack. Systems that
dynamically load objects and components are susceptible to evil components that do
bad things. If you have Singletons with global access, the bad things the evil
components can do are now expanded to the whole system. In an IOC based system,
it can only affect the parts that it can get a hold of. A properly designed system
will limit the number of things that a Component can attack.
So globally accessible Singletons can be a dangerous thing--not just for concurrency
reasons, but also for security reasons. If your system is completely closed, it
doesn't really make a whole lot of difference (other than lack of flexibility in
scaling your application). However, since logging is used in a wide variety of
contexts, it should not have a globally accessible singleton if it can avoid it.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
