Singleton pattern

Encyclopedia : S : SI : SIN : Singleton pattern

In software engineering, the singleton design pattern is used to restrict instantiation of a class to one (or a few) objects. 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. Before designing a class as a singleton, it is wise to consider whether it would be enough to design a normal class and just use one instance.

The singleton pattern is implemented by creating a class with a method that creates a new instance of the object 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.

Contents

1 Class diagram
2 Java example implementation
3 C++ example implementation
4 REALbasic example implementation
5 Example of usage with the factory method pattern
6 See also
7 External links

Class diagram

Java example implementation

A correct threadsafe Java programming language lazy-loaded solution known as the "Initialization On Demand Holder" idiom suggested by Bill Pugh follows:

public class Singleton 
private static class SingletonHolder 
public static Singleton getInstance() 
}

C++ example implementation

A possible C++ solution using Curiously Recurring Template Pattern (also known as Meyers singleton) where the singleton is a static local object (note: this solution is not thread-safe and is designed to give an idea of how singletons work rather than a solution usable in large-scale software project).

template<typename T> class Singleton

};

class OnlyOne : public Singleton
;

REALbasic example implementation

An example REALbasic solution uses a "Shared" method (available only in REALbasic 2006r1 or greater) to provide the instance. Note that this is thread-safe because REALbasic uses a cooperative threading model (instead of a preemptive one).

Class Singleton
Protected Sub Constructor()
// Initialization code defined here
End Sub
Shared Function Instance() as Singleton
static s as new Singleton
return s
End Function
End Class

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.

Singleton (LoadBalancer) defines an Instance operation that lets clients access its unique instance. Instance is a class operation responsible for creating and maintaining its own unique instance. Ensure a class has only one instance and provide a global point of access to it.

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).

is an abstract class that binds the various AWT components to particular native toolkit implementations. The Toolkit class has a  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 .

The binding performed by the toolkit allows, for example, the backing implementation of a 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.

External links

A [Pattern Enforcing Compiler™] that enforces the Singleton pattern amongst other patterns
[Description from the Portland Pattern Repository]
[Description] by Vince Huston
[Implementing the Singleton Pattern in C#] by Jon Skeet
[A Threadsafe C++ Template Singleton Pattern for Windows Platforms] by O. Patrick Barnes
[Implementing the Inheritable Singleton Pattern in PHP5]
[Singleton Pattern and Thread Safety]
[PHP patterns]
[Singleton Considered Stupid]
Article "[Double-checked locking and the Singleton pattern]" by Peter Haggar
Article "[Use your singletons wisely]" by J. B. Rainsberger
Article "[Simply Singleton]" by David Geary
Article "[Description of Singleton]" by Arun

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.