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 mixins 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

This is the default Singleton module provided by Ruby in singleton.rb. In contrast to static languages, the typical programmer need only understand the general theory behind the Singleton pattern rather than the specifics of this implementation. It should be used as a mixin to provide the pattern functionality to a specific class (see above).

module Singleton
  #  disable build-in copying methods
  def clone
    raise TypeError, "can't clone instance of singleton #{self.class}"
  end
  def dup
    raise TypeError, "can't dup instance of singleton #{self.class}"
  end

  #  default marshalling strategy
  def _dump(depth = -1)
    ''
  end

  module SingletonClassMethods
    # properly clone the Singleton pattern - did you know
    # that duping doesn't copy class methods?
    def clone
      Singleton.__init__(super)
    end

    def _load(str)
      instance
    end

    private

    #  ensure that the Singleton pattern is properly inherited
    def inherited(sub_klass)
      super
      Singleton.__init__(sub_klass)
    end
  end

  class << Singleton
    def __init__(klass)
      klass.instance_eval {
        @singleton__instance__ = nil
        @singleton__mutex__ = Mutex.new
      }
      def klass.instance
        return @singleton__instance__ if @singleton__instance__
        @singleton__mutex__.synchronize {
          return @singleton__instance__ if @singleton__instance__
          @singleton__instance__ = new()
        }
        @singleton__instance__
      end
      klass
    end

    private

    #  extending an object with Singleton is a bad idea
    undef_method :extend_object

    def append_features(mod)
      #  help out people counting on transitive mixins
      unless mod.instance_of?(Class)
        raise TypeError, "Inclusion of the OO-Singleton module in module #{mod}"
      end
      super
    end

    def included(klass)
      super
      klass.private_class_method  :new, :allocate
      klass.extend SingletonClassMethods
      Singleton.__init__(klass)
    end
  end

end

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