> -----Original Message-----
> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> [EMAIL PROTECTED] On Behalf Of Luke Dalessandro
>
> An obvious singleton application would be to define a static interface
> to
> the root of an abstract object hierarchy, and use an inherited class as
> your
> implementation.

Absolutely.  If you have a singleton, it can be passed around as an object.
That can be quite important sometimes.  For instance, once I was using a
library that used a static class to read in the configuration information
from the app.config.  That was absolutely fine for them, since they were
talking to one system and you could configure that with name-value pairs.
But I needed to talk to many systems, so I wanted to be able to configure
based on a configuration I provided, rather than the configuration in the
app.config.  That couldn't be done without modifying the library.

A nicer approach would have been for the library to take a configuration
object as a parameter, and the higher-level clients that use the library
implement the configuration object as a singleton (if they only talk to one
system) or some fancy-pants multi-system configuration objects if they need
that.

All of which makes me think that static classes and singletons depend on
context, and that context is typically dictated by the higher levels of the
program rather than the lower-level libraries.  So I would tend to encourage
the use of objects as parameters in libraries, rather than either static
classes or singletons - simply because you rarely know from the outset all
of the contexts in which the lower-level libraries will be used.

I think.

> You might also want to replace the instance during the
> lifetime of the application (you might be caching the instance based on
> some
> sort of CacheDependency), or provide quasi-singletons
> (per-thread/per-session, etc).

HttpContext.Current is a neat example of a fake singleton that provides a
per-thread instance, by the way.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to