Singletons are one of the patterns mentioned in the original Go4 text. They are not particularly clever, but are a structure suited to some types of problem. They are applicable when you wish to constrain the number of instances of an object. They are traditionally applied to unique resources like IO streams.
Software engineering references :
The widely used and traditional use of Singletons is to constrain the log object. The log messages need to appear in the same order that they where written in; this is easier with a single object doing the writing. When the logs use buffers, and particularly ring buffers; the issue is even more critical.
I use singletons to constrain the number of instances of memory intensive stateless utility classes. On a mature project I did for a previous employer, my output resources (i.e. the object holding PO internationalisation resources) added 300KB to a PHP process, which I didn't want many instances of. Controlling the number of occurrences also reduces disk activity, and parsing time for said resources.
Singletons are glorified global variables 1 with some behaviour added. In terms of the current project (iceline-project), one should be able to have several resource objects; so regardless of cost these cannot be a singleton. I agree with people [in the above articles] saying “must not contain business logic”. Another listed reason for building a Singleton is an AbstractFactory. Due the private constructor, and needing to extend the abstract class, I'm not sure that is clever. There aren't many situations where one needs several Factories, but having the right type of Factory is important.