The Singleton is the simplest and most widely used Design Pattern, and so it is often used as the starting point. It is how ever also the most widely misused, and one of the most controversial.

intent: to restrict a class to only one instance, and provide a global point of access to it.

motivation: Sometimes we want just a single instance of a class to exist in a system

structure:

example 1 (AS3):

public class Singleton{
 
    // holds the unique instance of the
    // Singleton in a class vars
    private static var _uniqueInstance:Singleton;
 
    // the constructor
    public function Singleton(validator:Number):void{
        // code
    }
 
    // provide access to the unique instance
    // through a class method
    public static function getInstance():Singleton{
 
        // lazy instantiation of unique instance:
        // if it don't exist, create it
        if (_uniqueInstance == null)
                _uniqueInstance=new Singleton( );
 
        //send it back
        return _uniqueInstance;
    }
}

and this is how the singleton instance is accessed:

var mySingleton:Singleton = Singleton.getInstance()

Pretty simple really, but there are some things to note

• the lazy instantiation means that the instance is not created unless it is needed, saving memory wastage. Now this presents no problems in AS (as it is single-threaded), but in a multi-threaded environment, the instantiation must be synchronised to prevent multiple instances being created by different threads.
• in AS, a constructor can not be private, so the above example is open to misuse, as the constructor can still be accessed by any client. It is not properly a Singleton yet, so some form of validation must be required to instantiate it.

example 2 (AS3):

public class Singleton{
 
    // the singleton validation key
    private static const SINGLETON_KEY:Number = Math.random();
 
    private static var _uniqueInstance:Singleton;
 
    // the constructor now requires an argument,
    // the SINGLETON_KEY which is private, different
    // for every application run, and can not be
    // accessed from outside the class
    public function Singleton(key:Number):void{
        if (key != SINGLETON_KEY)
                throw new Error("private constructor");
        // code
    }
 
    public static function getInstance():Singleton{
 
        // this time we pass in the key
        if (_uniqueInstance == null)
                _uniqueInstance=new Singleton(SINGLETON_KEY);
 
        return _uniqueInstance;
    }
}

Ok, so now only the static method getInstance() can create a new instance of the Singleton Class, trying to access the constructor with out the required key will throw an error.

We are good to go.

Or are we?

Singleton: the anti-pattern

1. just because one system needs only one instance of a certain class, doesn’t mean that another one does also. If this is the case, then the class should not be a Singleton, and to do so, is really just using a Singleton as a glorified global variable (GlobalVariablesAreBad). There will be a better way for a client to obtain the instance required.
2. because a Singleton manages its instance through a static method:
   1. sub-classing is possible, but fraught with complications
   2. it can not implement an interface
   3. all references must be hard-coded with the name of the class, promoting (as b does) tight coupling between classes
3. therefore, Singletons can not be polymorphic
4. a Singleton manages its own instantiation, but it also manages its own business logic. This violates the Single Responsibility Principle.
5. a Singleton’s state persists as long as the application is running – this is very bad for unit testing, as it out-lives any unit that is being tested (apparently).

conclusion

• Before you make a class a Singleton, ask yourself this: will it be implemented in exactly the same way for every client that will ever use it and always be required to have a single instance? If the answer is yes, then A Singleton is a valid choice.
• If you encapsulate the management of the Singleton instance in another class, then the Singleton can implement an interface, can be sub-classed, if needed – be used as a non-Singleton, and be left to get on with its own business logic in polymorphic heaven.