singleton class

[Weronpc]

Someone tell me what's singleton class?

[Jason Fox]

A class that is meant to be instantiated only once. An example might be a player object in a video game. You can have countless koopas, but only one Mario. I've usually seen this implemented like this:

 
public class Singleton {
   private static Singleton s;
 
   // private constructors are the key
   // only this class can construct itself
   private Singleton() {} 
 
   // if another class wants an instance of this class,
   // it calls this static method (Singleton.getInstance())
   public static Singleton getInstance() {
      if (s == null) { // if there isn't an instance already, create one
         s = new Singleton();
      }
 
      // subsequent calls to this method will return the
      // same Singleton
      return s; 
   }
}

Hope this helps.

[Weronpc]

Thank you Jason,

I understand what is Singleton class now, but I just don't understand why or when will we need to use such class.

[fred rosenberger]

Something that controls access to a limited resource is one example of where you'd need a singleton. Say, a printer controller. you may have 50 applications that all want access to the printer. But only ONE thing should actually GIVE jobs to the printer.

Every app. that wants to print says "tell me where the printer spooler is", and then hands that it's job. if we didn't have a singleton pattern here, then my EMACS editor would get one print spooler, and your VI editor would get it's own spooler.

Now, which spooler tells the printer what to do? both expect themselves to be the ONLY guys in town who tells the printer when/what to print. but i've got two. this doesn't make any sense.

with a singleton, both processes get access to the SAME spooler. there is only one, and can ONLY be one. and there SHOULD only be one.

does that make sense?

[Kris Philippaerts]

In practice, Singletons should be avoided where possible. Singletons make it very difficult to mock your code, which makes it difficult to properly unit test your classes. A better solutions is inversion of control where you create your instance only once, and pass it forward to every method that needs it.

Singletons are often used for service locators. Service locators are java classes that manage 'services' (in fact any java class you want), and can force a singleton behaviour of your class, without the need of a real singleton implementation of your class. But even service locators can be passed by inversion of control...

And a little remark on the code Jason Fox provided. This code is not thread safe: the thread may be stopped right after the (s == null) test, before the creation of the singleton. So, from the moment you use this code in a multithreaded environment, you are not sure of the singleton behaviour. Making this code thread safe will require you to make the method synchronized. But synchronized methods are slow, and should be avoided in 'normal' code. So an other solution is to instantiate the singleton at the declaration of the instance field. This has the drawback that you will have an instance of the class from the moment the class is accessed for the first time. But most of the time the first access to a singleton class would be a getInstance() call, so this isn't such a problem.

Regards,
Kris
[ June 28, 2004: Message edited by: Kris Philippaerts ]

[Jason Fox]

Well, I was trying to show the basics, not go into thread-safe programming ,etc. For a treatise on thread-safe singletons, I recommend http://www.javaworld.com/javaworld/javaqa/2002-01/02-qa-0125-singleton4.html

As far as avoiding singletons, I completely disagree. I tend to follow Fred's line of thinking, and use them in real-world situations where they make sense. I also think that that the idea of strongly enforcing the instantiation of a class outside of the class itself kind of falls apart when there are other developers working on the same project (who might not have gotten the memo ), and that enforcing the singleton pattern at the code-level makes sense. I've noticed that a lot of programmers either use them too much or avoid them too much, and there seems to be some kind of wierd mythos/stygma attached to them (and other design patterns as well)
[ June 28, 2004: Message edited by: Jason Fox ]

[Andrei Socaciu]

I agree with Kris, one should be careful when choosing to use a singleton. Besides being hard to unit-test, there is another issue: the singleton pattern guarantees one instance per classloader, not jvm so you might be in for a surprise... For the same reason singletons are not good as service locators in distributed applications, you might end up with multiple instances. The preffered way for looking up service locators is to use a registry.

Andrei

[fred rosenberger]

Originally posted by Andrei Socaciu:
I agree with Kris, one should be careful when choosing to use a singleton.

Andrei

Yes, but one should be careful no matter WHAT design pattern one is thinking of using.
[ June 30, 2004: Message edited by: fred rosenberger ]

[Jason Fox]

I hear the phrases 'never' or 'always' attached to a lot of design patters/methodologies. There was a post a while back (can't find it) about an author who advocated always writing an interface for every class, as an example. Now, as far as singletons go, the idea of always avoiding them whenever possible to me seems strange. The caveat about multiple JVMs is very true, but I do a good 75% of my java on the embedded/micro side, so multiple jvms is not something I'm worried about (not everyone is writing distributed/server-side java).