CSharp/C#, Proper Singleton Design in C#

PJ
#1 / 25

Proper Singleton Design in C#

Design #1:

public class SingleTon
{
private SingleTon() { }

public static string Method1
{
return "Hello";
}

Quote:

}

...
Console.Write SingleTon.Method1;
...

Design #2:

public class SingleTon
{
public static SingleTon Instance;
static SingleTon()
{
Instance = new SingleTon();
}

public static string Method1
{
return "Hello";
}

Quote:

}

...
Console.Write SingleTon.Instance.Method1
...

Which design is considered better practice? An old article on msdn used the
latter design, but I don't see what the issue is with Design #1 if the
default constructor is private. I really appreciate any feedback on this...

TIA~ PJ

Sun, 30 Jan 2005 02:47:26 GMT

Joerg Joos
#2 / 25

Proper Singleton Design in C#

Quote:

> Design #1:

> public class SingleTon
> {
> private SingleTon() { }

> public static string Method1
> {
> return "Hello";
> }
> }
> ...
> Console.Write SingleTon.Method1;
> ...

> Design #2:

> public class SingleTon
> {
> public static SingleTon Instance;
> static SingleTon()
> {
> Instance = new SingleTon();
> }

> public static string Method1
> {
> return "Hello";
> }
> }
> Which design is considered better practice? An old article on msdn used
the
> latter design, but I don't see what the issue is with Design #1 if the
> default constructor is private. I really appreciate any feedback on

this...

[Is SingleTon some sort of pun?]

The idea of a singleton is to have exactly one instance of a class. Only #2
is a true singleton, and it should be public static readonly. #1 is only a
means to prevent instantiation of (helper) classes for which instances are
meaningless, e.g. if they're only a namespace for static methods.

Cheers,

--
Joerg Jooss

Sun, 30 Jan 2005 03:15:09 GMT

Mathias Axelsso
#3 / 25

Proper Singleton Design in C#

Quote:

> Design #1:

This isn't a singleton. A singleton class will always exist in one instance.
A proper design would be more like the one in your second example, but with
some changes:

public class Singleton
{
private static Singleton _Instance = null;

private Singleton()
{
}

public static Singleton GetInstance()
{
if (_Instance == null)
{
_Instance = new Singleton();
}

return _Instance;
}

public string Method1()
{
return "Hello world!";
}

Quote:

}

To use it:

Singleton mySingleton = Singleton.GetInstance();

Console.WriteLine(mySingleton.Method1());

What you want to do is use the GetInstance() method to get a reference to
the object, and that call will initialize the one object that will be
created, if it isn't already created. Then it return that reference to you,
and you can use it to call the methods. You don't need to make the other
methods (Method1 for example) static, because you want to access them
through an object instance.

--
Mathias

Sun, 30 Jan 2005 03:26:58 GMT

Greg Ewin
#4 / 25

Proper Singleton Design in C#

PJ, #1 isn't a Singleton at all since no instance is ever made of your
class. In this case your SingleTon class is just a wrapper for your static
method.

#2 is almost a singleton, just change your instance declaration to

public static readonly.

You could also initialize your instance by changing the Instance declaration
to

public static readonly SingleTon Instance = new SingleTon();

There's a new article on MSDN at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbd...
singletondespatt.asp
--
Greg
http://www.claritycon.com/

Quote:

> Design #1:

> public class SingleTon
> {
> private SingleTon() { }

> public static string Method1
> {
> return "Hello";
> }
> }
> ...
> Console.Write SingleTon.Method1;
> ...

> Design #2:

> public class SingleTon
> {
> public static SingleTon Instance;
> static SingleTon()
> {
> Instance = new SingleTon();
> }

> public static string Method1
> {
> return "Hello";
> }
> }
> ...
> Console.Write SingleTon.Instance.Method1
> ...

> Which design is considered better practice? An old article on msdn used
the
> latter design, but I don't see what the issue is with Design #1 if the
> default constructor is private. I really appreciate any feedback on
this...

> TIA~ PJ

Sun, 30 Jan 2005 03:33:12 GMT

PJ
#5 / 25

Proper Singleton Design in C#

ok, but isn't #1 providing these (helper) static methods through an instance
of itself?

say we modify #1:

public class Singleton
{
private static Hashtable list;

private Singleton() { }
static Singleton()
{
list = new Hashtable();
}

public static MyObject GetItem(int id)
{
if (!list.ContrainsKey(id))
{
// create new object and put in hashtable
}
return (MyObject)list[id];
}

Quote:

}

...
MyObject obj = Singleton.GetItem(12);
...

now, the class is still not creating an instance of itself in the static
constructor and the client is still accessing methods on the class directly
rather than through an instance member, but can't I be assured that there is
still only one instance? Can't I be assured that only one Hashtable will
exist for my set of objects? If not...why not???

Quote:

> > Design #1:

> > public class SingleTon
> > {
> > private SingleTon() { }

> > public static string Method1
> > {
> > return "Hello";
> > }
> > }
> > ...
> > Console.Write SingleTon.Method1;
> > ...

> > Design #2:

> > public class SingleTon
> > {
> > public static SingleTon Instance;
> > static SingleTon()
> > {
> > Instance = new SingleTon();
> > }

> > public static string Method1
> > {
> > return "Hello";
> > }
> > }
> > Which design is considered better practice? An old article on msdn used
> the
> > latter design, but I don't see what the issue is with Design #1 if the
> > default constructor is private. I really appreciate any feedback on
> this...

> [Is SingleTon some sort of pun?]

> The idea of a singleton is to have exactly one instance of a class. Only
#2
> is a true singleton, and it should be public static readonly. #1 is only a
> means to prevent instantiation of (helper) classes for which instances are
> meaningless, e.g. if they're only a namespace for static methods.

> Cheers,

> --
> Joerg Jooss

Sun, 30 Jan 2005 03:34:15 GMT

Greg Ewin
#6 / 25

Proper Singleton Design in C#

PJ, firstly, you never initialize your variable list because your
constructor is never called. Secondly, you never check to make sure an
instance of list hasn't been created already. In this case you would just
overwrite the existing instance everytime the Singleton constructor was
called. See my post and Mathias's post for sample code which definitely
implements the singleton design pattern.

--
Greg
http://www.claritycon.com/

Quote:

> ok, but isn't #1 providing these (helper) static methods through an
instance
> of itself?

> say we modify #1:

> public class Singleton
> {
> private static Hashtable list;

> private Singleton() { }
> static Singleton()
> {
> list = new Hashtable();
> }

> public static MyObject GetItem(int id)
> {
> if (!list.ContrainsKey(id))
> {
> // create new object and put in hashtable
> }
> return (MyObject)list[id];
> }
> }

> ...
> MyObject obj = Singleton.GetItem(12);
> ...

> now, the class is still not creating an instance of itself in the static
> constructor and the client is still accessing methods on the class
directly
> rather than through an instance member, but can't I be assured that there
is
> still only one instance? Can't I be assured that only one Hashtable will
> exist for my set of objects? If not...why not???

> > > Design #1:

> > > public class SingleTon
> > > {
> > > private SingleTon() { }

> > > public static string Method1
> > > {
> > > return "Hello";
> > > }
> > > }
> > > ...
> > > Console.Write SingleTon.Method1;
> > > ...

> > > Design #2:

> > > public class SingleTon
> > > {
> > > public static SingleTon Instance;
> > > static SingleTon()
> > > {
> > > Instance = new SingleTon();
> > > }

> > > public static string Method1
> > > {
> > > return "Hello";
> > > }
> > > }
> > > Which design is considered better practice? An old article on msdn
used
> > the
> > > latter design, but I don't see what the issue is with Design #1 if the
> > > default constructor is private. I really appreciate any feedback on
> > this...

> > [Is SingleTon some sort of pun?]

> > The idea of a singleton is to have exactly one instance of a class. Only
> #2
> > is a true singleton, and it should be public static readonly. #1 is only
a
> > means to prevent instantiation of (helper) classes for which instances
are
> > meaningless, e.g. if they're only a namespace for static methods.

> > Cheers,

> > --
> > Joerg Jooss

Sun, 30 Jan 2005 03:44:43 GMT

jim moor
#7 / 25

Proper Singleton Design in C#

Quote:

> ok, but isn't #1 providing these (helper) static methods through an
instance
> of itself?

No, you're missing the point. Much of the intent of a singleton is to avoid
static methods, that way child classes of the singleton can selectively
modify its behavior (to this end methods should really be virtual as well).

Sun, 30 Jan 2005 03:42:45 GMT

J.K.
#8 / 25

Proper Singleton Design in C#

In Design #1, where do you store the single instance if you need to access
it in the future? If the only thing for this class to do is to write out a
message, both designs are fine.

Quote:

> Design #1:

> public class SingleTon
> {
> private SingleTon() { }

> public static string Method1
> {
> return "Hello";
> }
> }
> ...
> Console.Write SingleTon.Method1;
> ...

> Design #2:

> public class SingleTon
> {
> public static SingleTon Instance;
> static SingleTon()
> {
> Instance = new SingleTon();
> }

> public static string Method1
> {
> return "Hello";
> }
> }
> ...
> Console.Write SingleTon.Instance.Method1
> ...

> Which design is considered better practice? An old article on msdn used
the
> latter design, but I don't see what the issue is with Design #1 if the
> default constructor is private. I really appreciate any feedback on
this...

> TIA~ PJ

Sun, 30 Jan 2005 03:52:31 GMT

Jon Skee
#9 / 25

Proper Singleton Design in C#

WARNING: I'm a newcomer to C#. This *may* be rubbish. I'd be grateful if
those with more experience (Chad!) could check it carefully - any
corrections *very* welcome, as I'm certainly going to need to know this
stuff...

Quote:

> > Design #1:

> This isn't a singleton. A singleton class will always exist in one instance.
> A proper design would be more like the one in your second example, but with
> some changes:

> public class Singleton
> {
> private static Singleton _Instance = null;

> private Singleton()
> {
> }

> public static Singleton GetInstance()
> {
> if (_Instance == null)
> {
***
> _Instance = new Singleton();
> }

> return _Instance;
> }

Note that this isn't thread-safe. You can end up with two instances of
the class if two threads reach the line marked "***" at the same time.
There are various ways to solve this. The simplest way is to synchronize
the GetInstance method, eg:

public static Singleton GetInstance()
{
lock (typeof (Singleton))
{
if (_Instance == null)
{
_Instance = new Singleton();
}
return _Instance;
}

Quote:

}

(Btw, does C# really not have the equivalent of the synchronized method
modifier in Java? It's only syntactic sugar, but I think it's a bit
handier than the above.)

This has the disadvantage that you end up locking every time you enter
the method. There is a way of getting round this, which I gather works
with the C# memory model, but *doesn't* work in Java. It's called
double-check locking:

public static Singleton GetInstance()
{
if (_Instance == null)
{
lock (typeof (Singleton))
{
if (_Instance == null)
{
_Instance = new Singleton();
}
}
}
return _Instance;

Quote:

}

The reasons why it doesn't work in Java are quite scary, but there is an
easy way round it using static initialisers which can also be done in C#
with static constructors:

static Singleton()
{
Instance = new Singleton();

Quote:

}

This will work, but won't be as lazy as using the following slightly
ghastly hack which certainly works in Java and which should, I believe,
work in C# as well:

class Singleton
{
private Singleton()
{
}

public static void SayHi()
{
System.Console.WriteLine ("Hi");
}

public static Singleton GetInstance()
{
return SingletonHolder.instance;
}

private class SingletonHolder
{
static readonly Singleton instance;

static SingletonHolder
{
instance = new Singleton();
}
}

Quote:

}

This allows other static methods of Singleton (such as "SayHi" above) to
be called without instantiating the Singleton, and the only locking
needed is that done automatically by the JVM^H^H^H CLR to make sure that
classes are only loaded once.

--

http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Sun, 30 Jan 2005 05:10:21 GMT

PJ
#10 / 25

Proper Singleton Design in C#

Thanks everyone for your informative responses. I'll take a look at that
new article as well.

In the "Helper" class scenario that is apparently design 1, my tests show
the static constructor run before the first static method call on the class.

Usually, i declare my hashtable member like so, rather than instantiation in
a static constructor.
private static Hashtable list = Hashtable.Synchronized(new Hashtable());

Additionally, subsequent calls (even sometimes after stopping debugging and
starting again) successfully find members in my Hashtable
if (!list.ContainsKey(id)) evaluates to false.

This is the functionality I desire...one instance of a list of my objects to
be provided to clients in the process. Is it that there is no guarantee
that an instance of a "helper" class will not be garbage collected unless it
creates and controls and instance of itself?

With the proper singleton design pattern, what happens when all references
of this singular Instance member go out of reference? How is it that this
instance is not garbage collected? Or is the whole idea only to make sure
that not more than one instance exists....not necessarily that one instance
always exists?

Quote:

> In Design #1, where do you store the single instance if you need to access
> it in the future? If the only thing for this class to do is to write out a
> message, both designs are fine.

> > Design #1:

> > public class SingleTon
> > {
> > private SingleTon() { }

> > public static string Method1
> > {
> > return "Hello";
> > }
> > }
> > ...
> > Console.Write SingleTon.Method1;
> > ...

> > Design #2:

> > public class SingleTon
> > {
> > public static SingleTon Instance;
> > static SingleTon()
> > {
> > Instance = new SingleTon();
> > }

> > public static string Method1
> > {
> > return "Hello";
> > }
> > }
> > ...
> > Console.Write SingleTon.Instance.Method1
> > ...

> > Which design is considered better practice? An old article on msdn used
> the
> > latter design, but I don't see what the issue is with Design #1 if the
> > default constructor is private. I really appreciate any feedback on
> this...

> > TIA~ PJ

Sun, 30 Jan 2005 05:11:19 GMT

Jon Skee
#11 / 25

Proper Singleton Design in C#

Quote:

> Thanks everyone for your informative responses. I'll take a look at that
> new article as well.

> In the "Helper" class scenario that is apparently design 1, my tests show
> the static constructor run before the first static method call on the class.

With this kind of thing, it's best not to rely on tests: check the
language spec. (It's amazing what threading problems only crop up on
production systems if you leave it to testing :) Fortunately you're
correct in this respect, as section 10.11 of the spec shows:

<quote>
The static constructor for a class executes at most once in a given
application domain. The execution of a static constructor is triggered
by the first of the following events to occur within an application
domain:
An instance of the class is created.
Any of the static members of the class are referenced.
If a class contains the Main method (3.1) in which execution begins,
the static constructor for that class executes before the Main method is
called. If a class contains any static fields with initializers, those
initializers are executed in textual order immediately prior to
executing the static constructor.
</quote>

Quote:

> Usually, i declare my hashtable member like so, rather than instantiation in
> a static constructor.
> private static Hashtable list = Hashtable.Synchronized(new Hashtable());

The last part of the paragraph above neatly deals with that.

Quote:

> Additionally, subsequent calls (even sometimes after stopping debugging and
> starting again) successfully find members in my Hashtable
> if (!list.ContainsKey(id)) evaluates to false.

Yes, I'd expect that.

Quote:

> This is the functionality I desire...one instance of a list of my objects to
> be provided to clients in the process. Is it that there is no guarantee
> that an instance of a "helper" class will not be garbage collected unless it
> creates and controls and instance of itself?

> With the proper singleton design pattern, what happens when all references
> of this singular Instance member go out of reference? How is it that this
> instance is not garbage collected? Or is the whole idea only to make sure
> that not more than one instance exists....not necessarily that one instance
> always exists?

The class still has a reference to the instance. It's only when the
class itself is garbage collected (which I suspect happens when the
application domain is garbage collected - that seems to be a sort of
parallel for ClassLoader in Java :) that the instance will be collected.

--

http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Sun, 30 Jan 2005 05:29:52 GMT

PJ
#12 / 25

Proper Singleton Design in C#

excellent Jon, I greatly appreciate your time.

There seems to be much confusion on this...the Feb article IS the original
article I read that I was calling "old" and the author definately
communicates the "proper" singleton design in c# is for the class to create
an instance of itself in a public static readonly member as many on this
board have suggested.

However, if the goal is to really provide a set of data through one instance
of a class in a given app domain, why can't this be accomplished by simply
setting your default constructor to private and providing the data through
static members and methods? I like the benefit of not having to enforce
clients to reference the instance member. Isn't this what MS is doing with
System.DateTime.Now? We are not using System.DateTime.Instance().Now.

Jim Moore made a good point that having an internal member instance gives
you the ability to not use static methods, which is obviusly desirable if
this class will be inherited.

Quote:

> > Thanks everyone for your informative responses. I'll take a look at
that
> > new article as well.

> > In the "Helper" class scenario that is apparently design 1, my tests
show
> > the static constructor run before the first static method call on the
class.

> With this kind of thing, it's best not to rely on tests: check the
> language spec. (It's amazing what threading problems only crop up on
> production systems if you leave it to testing :) Fortunately you're
> correct in this respect, as section 10.11 of the spec shows:

> <quote>
> The static constructor for a class executes at most once in a given
> application domain. The execution of a static constructor is triggered
> by the first of the following events to occur within an application
> domain:
> An instance of the class is created.
> Any of the static members of the class are referenced.
> If a class contains the Main method (3.1) in which execution begins,
> the static constructor for that class executes before the Main method is
> called. If a class contains any static fields with initializers, those
> initializers are executed in textual order immediately prior to
> executing the static constructor.
> </quote>

> > Usually, i declare my hashtable member like so, rather than
instantiation in
> > a static constructor.
> > private static Hashtable list = Hashtable.Synchronized(new Hashtable());

> The last part of the paragraph above neatly deals with that.

> > Additionally, subsequent calls (even sometimes after stopping debugging
and
> > starting again) successfully find members in my Hashtable
> > if (!list.ContainsKey(id)) evaluates to false.

> Yes, I'd expect that.

> > This is the functionality I desire...one instance of a list of my
objects to
> > be provided to clients in the process. Is it that there is no guarantee
> > that an instance of a "helper" class will not be garbage collected
unless it
> > creates and controls and instance of itself?

> > With the proper singleton design pattern, what happens when all
references
> > of this singular Instance member go out of reference? How is it that
this
> > instance is not garbage collected? Or is the whole idea only to make
sure
> > that not more than one instance exists....not necessarily that one
instance
> > always exists?

> The class still has a reference to the instance. It's only when the
> class itself is garbage collected (which I suspect happens when the
> application domain is garbage collected - that seems to be a sort of
> parallel for ClassLoader in Java :) that the instance will be collected.

> --

> http://www.pobox.com/~skeet/
> If replying to the group, please do not mail me too

Sun, 30 Jan 2005 06:11:14 GMT

Chad Myer
#13 / 25

Proper Singleton Design in C#

Quote:

> excellent Jon, I greatly appreciate your time.

> There seems to be much confusion on this...the Feb article IS the original
> article I read that I was calling "old" and the author definately
> communicates the "proper" singleton design in c# is for the class to
create
> an instance of itself in a public static readonly member as many on this
> board have suggested.

> However, if the goal is to really provide a set of data through one
instance
> of a class in a given app domain, why can't this be accomplished by simply
> setting your default constructor to private and providing the data through
> static members and methods? I like the benefit of not having to enforce
> clients to reference the instance member. Isn't this what MS is doing
with
> System.DateTime.Now? We are not using System.DateTime.Instance().Now.

That's not quite a singleton as you can have multiple instances of
DateTime. Not only that, but .Now creates a new DateTime object that
reflects the time of the object's creation, so it's not even
persistent like a Singleton.

What you were talking about earlier is just a static-only class
which isn't exactly a Singleton although there are those who refer
to it as such.

A singleton has one and only one instance of itself and doesn't
let anyone create another instance of it.

A static-only class has no instance, no one can create an instance,
and provides only static methods that maintain no state.

Static-only classes are good in many cases, so if that's the
way you want to go, it will probably be a good idea.

Quote:

> Jim Moore made a good point that having an internal member instance gives
> you the ability to not use static methods, which is obviusly desirable if
> this class will be inherited.

Yep, that's one example where static-only classes aren't preferable.

-c

- Show quoted text -

Quote:

> > > Thanks everyone for your informative responses. I'll take a look at
> that
> > > new article as well.

> > > In the "Helper" class scenario that is apparently design 1, my tests
> show
> > > the static constructor run before the first static method call on the
> class.

> > With this kind of thing, it's best not to rely on tests: check the
> > language spec. (It's amazing what threading problems only crop up on
> > production systems if you leave it to testing :) Fortunately you're
> > correct in this respect, as section 10.11 of the spec shows:

> > <quote>
> > The static constructor for a class executes at most once in a given
> > application domain. The execution of a static constructor is triggered
> > by the first of the following events to occur within an application
> > domain:
> > An instance of the class is created.
> > Any of the static members of the class are referenced.
> > If a class contains the Main method (3.1) in which execution begins,
> > the static constructor for that class executes before the Main method is
> > called. If a class contains any static fields with initializers, those
> > initializers are executed in textual order immediately prior to
> > executing the static constructor.
> > </quote>

> > > Usually, i declare my hashtable member like so, rather than
> instantiation in
> > > a static constructor.
> > > private static Hashtable list = Hashtable.Synchronized(new
Hashtable());

> > The last part of the paragraph above neatly deals with that.

> > > Additionally, subsequent calls (even sometimes after stopping
debugging
> and
> > > starting again) successfully find members in my Hashtable
> > > if (!list.ContainsKey(id)) evaluates to false.

> > Yes, I'd expect that.

> > > This is the functionality I desire...one instance of a list of my
> objects to
> > > be provided to clients in the process. Is it that there is no
guarantee
> > > that an instance of a "helper" class will not be garbage collected
> unless it
> > > creates and controls and instance of itself?

> > > With the proper singleton design pattern, what happens when all
> references
> > > of this singular Instance member go out of reference? How is it that
> this
> > > instance is not garbage collected? Or is the whole idea only to make
> sure
> > > that not more than one instance exists....not necessarily that one
> instance
> > > always exists?

> > The class still has a reference to the instance. It's only when the
> > class itself is garbage collected (which I suspect happens when the
> > application domain is garbage collected - that seems to be a sort of
> > parallel for ClassLoader in Java :) that the instance will be collected.

> > --

> > http://www.pobox.com/~skeet/
> > If replying to the group, please do not mail me too

Sun, 30 Jan 2005 06:31:01 GMT

Jon Skee
#14 / 25

Proper Singleton Design in C#

Quote:

> excellent Jon, I greatly appreciate your time.

> There seems to be much confusion on this...the Feb article IS the original
> article I read that I was calling "old" and the author definately
> communicates the "proper" singleton design in c# is for the class to create
> an instance of itself in a public static readonly member as many on this
> board have suggested.

Right. I can't think off-hand why it's more common in Java to have a
method returning the instance rather than just having a public static
final (equivalent of readonly) member. It means you can't do the "extra
lazy" evaluation where you can have static methods which don't end up
causing the singleton to be instantiated, but that's the only thing I
can think of right now. That could well be due to it being nearly 1.30am
though :)

Quote:

> However, if the goal is to really provide a set of data through one instance
> of a class in a given app domain, why can't this be accomplished by simply
> setting your default constructor to private and providing the data through
> static members and methods? I like the benefit of not having to enforce
> clients to reference the instance member. Isn't this what MS is doing with
> System.DateTime.Now? We are not using System.DateTime.Instance().Now.

It's nice to use instances because then other classes don't need to know
that it's a singleton - they just get something they can use. For
instance, you could be implementing an interface in the singleton. It
also means that you can very easily change your code from being a
singleton to being a factory which might generate a few instances rather
than one.

Quote:

> Jim Moore made a good point that having an internal member instance gives
> you the ability to not use static methods, which is obviusly desirable if
> this class will be inherited.

A singleton which can be subclassed is no longer a singleton, of course.

--

http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

Sun, 30 Jan 2005 08:24:21 GMT

Courageou
#15 / 25

Proper Singleton Design in C#

Quote:

>Which design is considered better practice?

Neither:

public class Singleton
{
private Singleton instance;
private Singleton(){}

public Singleton GetInstance()
{
if ( instance==null ) instance = new Singleton();
return instance;
}

Quote:

}

Sun, 30 Jan 2005 08:43:04 GMT