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:
Hope this helps.
Joined: Jun 12, 2004
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.
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?
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
In practice, Singletons should be avoided where possible. Singletons make it very difficult to mock your code, which makes it difficult to properly unittest 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.
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 ]
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.
Originally posted by Andrei Socaciu: I agree with Kris, one should be careful when choosing to use a singleton.
Yes, but one should be careful no matter WHAT design pattern one is thinking of using. [ June 30, 2004: Message edited by: fred rosenberger ]
Joined: Jan 22, 2004
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).