Singleton pattern

From Wikipedia, the free encyclopedia

In software engineering, the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. Sometimes it is generalized to systems that operate more efficiently when only one or a few objects exist. It is also considered an anti-pattern since it is often used as a euphemism for global variable.

1 Implementation
2 Class diagram
3 Example implementations
4 Prototype-based singleton
5 Example of usage with the factory method pattern
6 A singleton Pattern
7 See also
8 References
9 External links

[edit] Implementation

The singleton pattern is implemented by creating a class with a method that creates a new instance of the class if one does not exist. If an instance already exists, it simply returns a reference to that object. To make sure that the object cannot be instantiated any other way, the constructor is made either private or protected. Note the distinction between a simple static instance of a class and a singleton: although a singleton can be implemented as a static instance, it can also be lazily constructed, requiring no memory or resources until needed.

The singleton pattern must be carefully constructed in multi-threaded applications. If two threads are to execute the creation method at the same time when a singleton does not yet exist, they both must check for an instance of the singleton and then only one should create the new one. If the programming language has concurrent processing capabilities the method should be constructed to execute as a mutually exclusive operation.

The classic solution to this problem is to use mutual exclusion on the class that indicates that the object is being instantiated.

[edit] Class diagram

[edit] Example implementations

[edit] Java

A thread-safe Java programming language lazy-loaded solution suggested by Bill Pugh, known as the initialization on demand holder idiom, follows:

public class Singleton {
  // Private constructor suppresses generation of a (public) default constructor
  private Singleton() {}

  private static class SingletonHolder {
    private static Singleton instance = new Singleton();
  } 

  public static Singleton getInstance() {
    return SingletonHolder.instance;
  }
}

[edit] PHP 5

Singleton pattern in PHP 5:

<?php
class Singleton {
  // object instance
  private static $instance;
  
  private function __construct() {}
  private function __clone() {}
  
  public static function getInstance() {
    if (self::$instance === null) {
      self::$instance = new Singleton();
    }
    return self::$instance;
  }
}
?>

[edit] C++ (using pthreads)

A common design pattern for thread safety with the singleton class is to use double-checked locking. However, due to the ability of optimizing compilers to re-order instructions, and the absence of any consideration being given to multiple threads of execution in the language standard, double-checked locking is intrinsically prone to failure in C++. There is no model — other than runtime libraries (e.g. POSIX threads, designed to provide concurrency primitives) — that can provide the necessary execution order.[1]

By adding a mutex to the singleton class, a thread-safe implementation may be obtained.

#include <pthread.h>

class Mutex
{
  public:
    Mutex()
    { pthread_mutex_init(&m, 0); }

    void lock()
    { pthread_mutex_lock(&m); }

    void unlock()
    { pthread_mutex_unlock(&m); }

  private:
    pthread_mutex_t m;
};

class MutexLocker
{
  public:
    MutexLocker(Mutex& pm): m(pm) { m.lock(); }
    ~MutexLocker() { m.unlock(); }
  private:
    Mutex& m;
};

class Singleton
{
  public:
    static Singleton& Instance();
    int example_data;
    ~Singleton() { }

  protected:
    Singleton(): example_data(42) { }

  private:
    static std::auto_ptr<Singleton> theSingleInstance;
    static Mutex m;
};

Singleton& Singleton::Instance()
{
    MutexLocker obtain_lock(m);
    if (theSingleInstance.get() == 0)
      theSingleInstance.reset(new Singleton);
    return *theSingleInstance;
}

std::auto_ptr<Singleton> Singleton::theSingleInstance;
Mutex Singleton::m;

#include <cstdio>
int main()
{
    printf("%d\n", Singleton::Instance().example_data);
    return 0;
}

Note the use of the MutexLocker class in the Singleton::Instance() function. The MutexLocker is being used as an RAII object, also known as scoped lock, guaranteeing that the mutex lock will be relinquished even if an exception is thrown during the execution of Singleton::Instance(), since the language specification pledges that the destructors of automatically allocated objects are invoked during stack unwind.

This implementation invokes the mutex-locking primitives for each call to Singleton::Instance(), even though the mutex is only needed once, the first time the method is called. To get rid of the extra mutex operations, the programmer can explicitly construct Singleton::theSingleInstance early in the program (say, in main); or, the class can be optimized (in this case, using pthread_once) to cache the value of the initialized pointer in thread-local storage.

[edit] C# (using generics)

This example is thread-safe with lazy initialization.

 /// <summary>
 /// Generic class implements singleton pattern.
 /// </summary>
 /// <typeparam name="T">
 /// Reference type. Important: Must have private constructor (not public).
 /// </typeparam>
 public class Singleton<T> where T : class
 {
   protected Singleton() { }
   public static T Instance
   {
     get { return SingletonCreator.instance; }
   }
   class SingletonCreator
   {
     // static SingletonCreator() { } redundant as it is created by the compiler automatically
     internal static readonly T instance = typeof(T).InvokeMember(typeof(T).Name,
                          BindingFlags.CreateInstance |
                          BindingFlags.Instance |
                          BindingFlags.NonPublic,
                          null, null, null) as T;
   }
 }

[edit] Python

According to influential Python programmer Alex Martelli, The Singleton design pattern (DP) has a catchy name, but the wrong focus—on identity rather than on state. The Borg design pattern has all instances share state instead.^[1] A rough consensus in the Python community is that sharing state among instances is more elegant, at least in Python, than is caching creation of identical instances on class initialization. Coding shared state is nearly transparent:

 class Borg:
    __shared_state = {}
    def __init__(self):
        self.__dict__ = self.__shared_state
    # and whatever else you want in your class -- that's all!

But with the new style class, this is a better solution, because only one instance is created:

class  Singleton (object):
    instance = None       
    def __new__(cls, *args, **kargs): 
        if cls.instance is None:
            cls.instance = object.__new__(cls, *args, **kargs)
        return cls.instance

#Usage
mySingleton1 =  Singleton()
mySingleton2 =  Singleton()

#mySingleton1 and  mySingleton2 are the same instance.
assert mySingleton1 is mySingleton2

Two Caveats:

The __init__-method is called every time you call Singleton().

If you want to inherit from the Singleton-class, instance should propably be a dictionary belonging explicitly to the Singleton-class.

class  InheritableSingleton (object):
    instances = {}
    def __new__(cls, *args, **kargs): 
        if InheritableSingleton.instances.get(cls) is None:
            InheritableSingleton.instances[cls] = object.__new__(cls, *args, **kargs)
        return InheritableSingleton.instances[cls]

[edit] Prototype-based singleton

In a prototype-based programming language, where objects but not classes are used, a "singleton" simply refers to an object without copies or that is not used as the prototype for any other object. Example in Io:

Foo := Object clone
Foo clone := Foo

[edit] Example of usage with the factory method pattern

The singleton pattern is often used in conjunction with the factory method pattern to create a system-wide resource whose specific type is not known to the code that uses it. An example of using these two patterns together is the Java Abstract Windowing Toolkit (AWT).

java.awt.Toolkit is an abstract class that binds the various AWT components to particular native toolkit implementations. The Toolkit class has a Toolkit.getDefaultToolkit() factory method that returns the platform-specific subclass of Toolkit. The Toolkit object is a singleton because the AWT needs only a single object to perform the binding and the object is relatively expensive to create. The toolkit methods must be implemented in an object and not as static methods of a class because the specific implementation is not known by the platform-independent components. The name of the specific Toolkit subclass used is specified by the "awt.toolkit" environment property accessed through System.getProperties().

The binding performed by the toolkit allows, for example, the backing implementation of a java.awt.Window to bound to the platform-specific java.awt.peer.WindowPeer implementation. Neither the Window class nor the application using the window needs to be aware of which platform-specific subclass of the peer is used.

[edit] A singleton Pattern

A singleton is a single instance of any class. It could be a given instance of a singleton class. More to the point though a singleton diagram is a design pattern that is used to show a single instantiation of the class. For example: Image:CPUprocess.bmp