Singleton usage is best suited for situations when you need to have full control on the number of instances of a class that are available at a specified moment. For more details you can consult GoF. Martin Fowler talks a little about it too.
Caches, pools and stateful interfaces (connections) to other systems are a couple examples I use. Servlets are singletons to avoid the overhead of creating and garbage collecting huge numbers of instances. (Anybody know if the theory is backed up by performance measurements?) [ November 18, 2004: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Singleton Pattern is mostly useful when your real-life entity is a singleton.
For example, you have a multi-threaded app that communicates with an external server. In this case, it's better to have a Singleton class that handles the communication with the server. Not only do you put all your communication logic in one place, but you can also control the access to the server. For example, the Singleton can pool connections to the server, control the number of concurrent connections to the server etc, etc
Originally posted by Jayesh Lalwani: Singleton Pattern is mostly useful when your real-life entity is a singleton.
For example, you have a multi-threaded app that communicates with an external server.
That's actually one of the examples where I find using a Singleton to be a suboptimal solution. (I just picked it because it was the last in this thread - I'm not convinced by the other examples, either.)
The reason is that the "only one server" requirement is likely more of a temporary coincidence than an unchanging fact of life.
The problem actually is not the "guarantee only one instance" part of the Singletons' definition, but the global access point to that one instance.
When the business people after a year of development find out that now they'd actually prefer to have two servers, your whole code is likely to be build on the premise that there is only one, and that they can access it through the static methods of the Singleton. It's going to become a refactoring nightmare.
That's why I would prefer the Just Create One pattern - simply create the one instance of the server at a central place and *pass that instance around*, so that all the other objects don't know where it's coming from and how much of them might exist. As a nice side effect, that will also make unittesting your code much easier.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 11, 2001
Originally posted by Stan James: Servlets are singletons to avoid the overhead of creating and garbage collecting huge numbers of instances.
Servlets aren't Singletons, but Just Create One's, aren't they?
Joined: Jan 29, 2003
Yeah, Just Create One is a beter description. I never drew the distinction that Singleton required a software solution that forced a single instance. But the GoF intent and implementation sections both say "to ensure a class only has one instance" so I guess I needed a refresher.
GoF implementation also has a neat section on subclassing singletons. Quite a few discussions say the inability to subclass is a drawback to singleton. Refreshers all around, bartender! [ November 20, 2004: Message edited by: Stan James ]