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.
Why would you do something like that? You don't think you can have multiple connections?
Anyway, forget about singletons. You almost never have a good reason to use them. Only when dependency injection becomes incredibly cumbersome and doesn't add much flexibility. A good example is a logger.
Loggers should be available to the entire application, so it's cumbersome to use dependency injection. Also, loggers are fairly safe to use. If you use the same logger by multiple classes concurrently, and something goes wrong, it probably won't break your code, because loggers are not essential to the operation of your program. Information only goes one way, from your program to your logger.
If the information goes from the singleton candidate to the program, make it read only. An example is configuration settings, encapsulated in a single class. This may be considered a poor example, because configuration settings should probably be broken up and passed as arguments to the classes that need them. Read-only configuration settings are also not very flexible, because they require you to restart a program when you want new settings to take effect.
So really, singletons have *very* limited use.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.