Derivable singleton class

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi all,
I'm quite new to C#.
I am trying to implement some basics reusable classes using this language
and the .NET Framework technology.

What I'm trying to do now is to implement a singleton class.

I did have a look at the Microsoft "Patterns and Practices" article
"Implementing Singleton in C#"
(http://msdn.microsoft.com/library/d...n-us/dnpatterns/html/ImpSingletonInCsharp.asp)
and I found it useful but I still have a problem: what I need is a
thread-safe approach, because I expect to use this piece of code in
multi-threaded applications, but I'd like my class to be not "sealed" because
I would put some generic methods in it and I would add some specific
implementations in derived classes.

In the article above, instead, the class provided to obtain thread-safety is
designed "sealed", so that it doesn't completely suits my needs.

Bottom line: how can I implement a singleton class which is derivable and
thread-safe?
Or am I just thinking the whole thing wrong?

Thanks in advance.

Cheers,
baba.
 
baba,

Is far as thread safety goes I don't think this is an issue if the singleto
design pattern. It is rather problem of the class itself. You need to make
its public members thread safe. The singleto design pattern just guarantees
that only one instance of the class exisits.

Regarding the inheritance of the singleton class it has been discussed in
the ng before. Even though the singleton pattern doesn't state that the
inheritance is not allowed, it is very unlikely. Enabling inheritance opens
backdoors for easily breaking the singleton effect of the pattern. It can be
implemented but the use of it is very limited.

I'd suggest reading Jon Skeet's blog (I hope Jon don't mind me posting this
link ) for an idea how to implemented soemething like this.
http://msmvps.com/blogs/jon.skeet/archive/2006/01/20/singleton_inheritance.aspx

If you look at the code you'll see what I mean by 'limited'
The type of the singleton object is determined upon type loading (which
happens once in the process (AppDomain) life time) You can't changed it
afterwards neither you can create singletons of different derived types in
the same application. If you could it would break the singleton effect.
 
Back
Top