A question about Singleton pattern

[Ravi Kiran Va]

Hi

This question is about Singleton Pattern .

Can anybody please tell me why is it necessary to have a static method which generally responsible to return the instance the class .

My question is why the word static is mantadatory ??

Thanks in advance

[Hong Anderson]

We aren't allowed to create a instance directly because the constructor is private or protected so we have to use a public static method to get the instance.

[Ravi Kiran Va]

Thank you .

The question is why to use static keyword .

[Marco Ehrentreich]

If you make the constructor private only the class itself can create an instance of this class via the "new" keyword. Therefore you need a way to trigger this creation from outside the class. And if you don't yet have an instance (= object) of the class you can only use static methods because they can be invoked on the class itself and don't need an object instance. Hope that makes it clearer

Marco

[Ravi Kiran Va]

Thank you Kengkaj Sathianpantarit and Marco Ehrentreich .

I am missing on the basics and trying to think something big .

[Marco Ehrentreich]

You're welcome

And don't worry, the singleton pattern is mostly considered bad design today anyway. So better don't care about it too much!

Marco

[Salil Vverma]

Hey Marco,

why would one consider singleton design pattern to be bad design, could you please throw some light on it ?

[David Newton]

Search the web--this is discussed all over the place.

[PrasannaKumar Sathiyanantham]

 public class databasedriver
{
  private static databasedriver ref;

  private databasedriver()
  {

  }

  public static databasedriver getDatabaseDriver()
  {
    if (ref == null)
        ref = new databasedriver();		
    return ref;
  }

  public Object clone()
	throws CloneNotSupportedException
  {
    throw new CloneNotSupportedException(); 
  }

}
   

If you consider the above example you will get an idea as to why we need a static method in a singleton class. As to the reason of why we need a singleton class let us consider a project with database connection(web project)... It is better design to have one connection open to the database and all the user requests to be processed through that connection. This can be achieved by using singleton class because it makes sure that only one object is created thereby providing a single thread(not in java sense) to the database.

As to the post that singleton is considered a bad practice no comments

[Marco Ehrentreich]

The general idea of a singleton is not bad at all. But the example above quickly shows some practical problems. The database example is indeed a typical singleton demonstration. The problem is that it's very likely that multiple database connections are needed in a multithreaded context (i.e. a servlet based web application) and this is exactly that type of application where the classic singleton pattern doesn't work as expected because it's not thread-safe and therefore it's very likely that there will be MORE than one instance of this class But there are (complicated) attempts, too, which make it really thread-safe although there are more incorrect examples which only try to make it thread-safe.

But the bigger problem is that this static creation method easily allows to hide the fact that you have created a global variable because you can access the singleton from everywhere in the application without explicitly declaring a dependency on that singleton class (you have it implicitly with the static method). And THAT is one of the main problems of the singleton pattern. You'll find lots of discussions here on JavaRanch or just Google for it

If you really need the concept of a singleton than there are better ways to handle resource management for example. They will save you a lot of trouble.

Marco

[Marco Ehrentreich]

As to the post that singleton is considered a bad practice no comments

What do you mean with this? Do you think it is NOT bad design? Ever worked with a big application which makes heavily use of such so-called singeltons? Or tried to make an application testable which consists of lots of those singeltons? Just curious why you said "no comments".

Marco

[Salil Vverma]

Hi Marco,

I agree with that the above code might give a chance of multiple object creation in a multiple threaded environment. We can prevent this by keeping the following section in a synchronized block but this would create an performance overhead.

 
  if (ref == null)  
         ref = new databasedriver();       
     return ref;
 

If you really need the concept of a singleton than there are better ways to handle resource management for example. They will save you a lot of trouble.

Could you please suggest what can be an alternate way to implement the singleton concept ?

[Marco Ehrentreich]

Hi Salil,

We can prevent this by keeping the following section in a synchronized block but this would create an performance overhead.

In fact there are alternative ways to using "synchronized" but lots of them are just too complicated for practical usage if you're not very familiar with concurrency on top of Java and the JVM. A big problem is, that it's often difficult to even know if you got it right when it comes to concurrency. Anyway, Brian Goetz gives lots of very good examples in his book "Java concurrency in practice".

Could you please suggest what can be an alternate way to implement the singleton concept ?

For example there are well known frameworks for dependency injection which can not only inject dependencies into another object but also manage the lifecycle of objects, i.e. the frameworks are also capable of taking care that only one instance of a particular class will be created which is then shared between all objects which depend on it. If you're building an enterprise or web application with JEE 6 for example you can benefit from singleton concepts already built into the platform.

If you need a singleton just to control access to limited resources like database connections there are often ready made opensource solutions you can use for resource pooling. These solutions are mostly more powerful and feature rich than a naive singleton implementation could be. Here again, if you're working with an enterprise or web application you typically can rely on the application server or servlet container to manage resources like database or mail server connections for you.

That said, I don't want to tell everybody here that you should never use a singleton under all circumstances. There are surely situations when a simple singleton is just good enough. You should just be aware of the negative effects the singleton pattern can have!

Marco

[manuel aldana]

singletons semantics have their place (e.g. inside ioc-containers you often have instances which are immutable and only one instance is necessary and available).

the danger is if you have mutable state singletons. they tend to end in hidden global variables in your app. then if problems occurs analyzation is very tricky and debugging is hell, especially in multithreaded scenarios.

mutable state singletons are an enemy for encapsulation and reasoning about side-effects of code-statements!

[Raj chiru]

Kengkaj Sathianpantarit wrote:We aren't allowed to create a instance directly because the constructor is private or protected so we have to use a public static method to get the instance.

And also you can easily attack the private constructor with Reflection,that's why we have declared a static method which generally responsible to return same object reference(All calls to Singleton.getInstance())