What is the better approach to implement Singleton pattern?

[Venkat Sadasivam]

Singleton is one of the frequently used and easily understandable
design pattern. Most of the tutorials and books give example of making
the constructor as private and exposing a static method which will
provide single instance. The common example they use is Runtime class
of JRE.

Is making constructor as private is the only way to implement
singleton pattern? Is that the best way to implement singleton
pattern?

Here is the complete article.
http://venkatsadasivam.wordpress.co...tter-approach-to-implement-singleton-pattern/

- Venkat

 

[Steve]

Singleton is one of the frequently used and easily understandable
design pattern. Most of the tutorials and books give example of making
the constructor as private and exposing a static method which will
provide single instance. The common example they use is Runtime class
of JRE.

Is making constructor as private is the only way to implement
singleton pattern? Is that the best way to implement singleton
pattern?

Here is the complete article.http://venkatsadasivam.wordpress.com/2008/03/27/what-is-the-better-ap...

- Venkat

In general the safest way to handle the singleton pattern is to
construct the object as a static variable and to hide the constructor
as you have described. Provide a static access method that simply
returns the static variable.

Sometime this doesn't work. Say if you have to delay the instantiation
of the object for some reason - something called lazy initialisation.
In this case you get into threading issues. These are addressed by the
'double locking' pattern. Although even that is contentious.

One big problem with singletons is dealing with multiple class
loaders. You're fine when dealing with a simple app. Once a web-server
such as Tomcat gets involved you start having to consider multiple
class loaders. It's not difficult to see the problem you'll get into
when you realise a singleton is really specific only to the class
loader that creates it.

Then you might consider using something like Spring to handle the
creation and 'glue' of you objects. Spring provides a sort of object
registry and can be configured to handle objects as singletons or not.

Rgds, Steve.

 

[John B. Matthews]

In general the safest way to handle the singleton pattern is to
construct the object as a static variable and to hide the constructor
as you have described. Provide a static access method that simply
returns the static variable.

[...]
The double-checked locking pattern is broken, unless synchronized.

[...]

Even then, double-checked locking is problematic:

<http://www-128.ibm.com/developerworks/java/library/j-dcl.html?loc=j>

John

 

[Arne Vajhøj]

Singleton is one of the frequently used and easily understandable
design pattern. Most of the tutorials and books give example of making
the constructor as private and exposing a static method which will
provide single instance. The common example they use is Runtime class
of JRE.

Is making constructor as private is the only way to implement
singleton pattern? Is that the best way to implement singleton
pattern?

Here is the complete article.
http://venkatsadasivam.wordpress.co...tter-approach-to-implement-singleton-pattern/

private constructor and private static instance and public static method
to get instance is the only way to implement the singleton pattern.

Other methods are not singleton as defined by GoF.

And you blog post is completely off - Math is not a singleton class.

A singleton class carry data that should exist in one copy.

Math is a bunch of static methods but no data.

In C# you can declare a class as static to indicate that it only
contains static.

OOP is good but occasionally problems are really procedural.

Arne

 

[Arne Vajhøj]

Sometime this doesn't work. Say if you have to delay the instantiation
of the object for some reason - something called lazy initialisation.
In this case you get into threading issues. These are addressed by the
'double locking' pattern. Although even that is contentious.

You do not get into any problems if you use synchronized properly.

You get into problem if using double locking, because it does not work.

One big problem with singletons is dealing with multiple class
loaders. You're fine when dealing with a simple app. Once a web-server
such as Tomcat gets involved you start having to consider multiple
class loaders. It's not difficult to see the problem you'll get into
when you realise a singleton is really specific only to the class
loader that creates it.

On the contrary - it would be a disaster if classloaders did not work
that way.

Different web apps are supposed to be independent of each other.

Arne

 

[Arne Vajhøj]

In general the safest way to handle the singleton pattern is to
construct the object as a static variable and to hide the constructor
as you have described. Provide a static access method that simply
returns the static variable.

[...]
The double-checked locking pattern is broken, unless synchronized.

[...]

Even then, double-checked locking is problematic:

<http://www-128.ibm.com/developerworks/java/library/j-dcl.html?loc=j>

It is amazing how much broken code and unreadable code has been written
to try and improve the performance of singleton pattern.

I don't think I have ever heard of a case where there were a
performance problem using plain straightforward synchronized.

Arne

 

[thufir]

Sometime this doesn't work. Say if you have to delay the instantiation
of the object for some reason - something called lazy initialisation. In
this case you get into threading issues. These are addressed by the
'double locking' pattern. Although even that is contentious.

I don't have it on hand, but in "effective java" by bloch, admittedly
old, I believe he advocates Singleton as a means of being thread safe.


-Thufir