CSC/ECE 517 Fall 2010/ch3 3f DF

The Singleton pattern in static and dynamic languages

Introduction

The Singleton design pattern ensures that there is no more than one instance of an object in existence at a time. This is accomplished by protecting the allocation and deallaction methods of the class to restrict them from general use. Instead of calling these methods directly, all requests for the object are routed through a public interface which only creates the object if it doesn't exist already. Upon creation, the object is stored in a class variable and this single instance is also returned to all future callers.

UML Diagram

Static Language Implementation

Below is a static language (C++) implementation of the Singleton pattern.

class MySingleton
{
  public:
    static MySingleton* Instance()
    {
      if(s_pSingletonObject == NULL)
        s_pSingletonObject = new MySingleton;
				
      return s_pSingletonObject;
    }
		
    static void Destroy()
    {
      if(s_pSingletonObject != NULL)
      {
        delete s_pSingletonObject;
        s_pSingletonObject = NULL;
      }
    }

    //Begin interface functions
    //...
    //End interface functions
		
  private:
    //Direct access to the constructor/destructor is prohibited
    MySingleton() {}
    virtual ~MySingleton() {}
		
    static MySingleton* s_pSingletonObject;
};

MySingleton::s_pSingletonObject = NULL;

Dynamic Language Implementation

Unlike static languages, dnyamic languages often provide pre-defined pattern implementations that may be added to a class. This is made possible by dynamic definitions which allow one piece of common code to access the class variables for each class they are included in.

Below is a dynamic language (Ruby) implementation of the Singleton pattern.

Usage

class MySingleton
  include Singleton

  # Begin interface methods
  # ...
  # End interface methods
end

Implementation

  Singleton pattern source code

Variations

Several differing variations of the Singleton pattern exist which take the core implementation idea and extend it to support specific situations. It should be noted that variations on the Singleton pattern are much more common in static languages due to the requirement of having to re-implement the pattern for each use. It is possible to achieve the same functionality in dynamically typed languages; however, it is far less intuitive. To do so in Ruby, for example, would require either the implementation of a variation on the provided Singleton module or monkey-patching it to behave as desired.

Multiple Instantiations

While the Singleton pattern's namesake arises out of there being a "single" instantiation of the class, it is somtimes used to created a fixed number of instantiations. In these situations, the singleton's accessor methods are parameterized to allow callers to specify which instance of the object they desire.

MySingleton* Instance(unsigned int uiInstanceNumber)

Lifetime & Scoping

The Singleton pattern is also commonly varied by modifying the lifetime of the instaniated object. Some implementations allow for a singleton to exist through the entire application lifetime. Others, such as the window state manager below, dynamically create and destroy the singleton as needed.

class MyWindow
{
  Open()
  {
    MyStateSingleton::Instance();
  }

  Close()
  {
    MyStateSingleton::Destroy();
  }
}

References

http://ruby-doc.org/stdlib/libdoc/singleton/rdoc/index.html

http://en.wikipedia.org/wiki/Singleton_pattern