This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Not quite, an instance of a singleton class is unique. There is only one of them in your program. The problems are 1) how to make sure the instance is unique, and 2) how do the various objects in your program know where to find the single unique instance of the singleton class.
You can use the singleton instance as many time as you like, even from multiple threads running simultaneously in your program. (This is perhaps important in solving problem 1.)
So how would you start making your very own singleton?
If you want something to be a singleton, you have to insure that not just anybody can call "new MySingletonClass()" - that could result in multiple copies of my singleton floating around. How can you "hide" the constructor(s) of your Singleton?
Now that you've hidden the constructor - you need to provide a "gatekeeper" method. That gatekeeper needs to be able to construct the singleton, and then return the same reference each time it's invoked. Try google'ing on "Factory Pattern".
Finally, since you want/must be able to invoke your factory without access to a constructor, the Factory method (and the storage for the singleton) need to be Class-level accessible rathe rthan instance-level. Take a look at what declaring something "static" does for you.
Advanced topics (such as, "Mainting Singleton-ness in the face of multiple ClassLoaders" and "Is Singleton really an Anti-Pattern?") left for future discussion.
(Who's learning how to answer "the JavaRanch way" by asking more questions or pointing out areas for investigation. Bear with me while I learn...)
In Theory, there is no difference between theory and practice.<br />In Practice, there is no relationship between theory and practice.