Singleton

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (Reverted edits by Ebybymic (Talk); changed back to last version by Mujtaba Alshakhouri)
 
(11 intermediate revisions by 7 users not shown)
Line 1: Line 1:
Singleton is a simple design pattern to ensure that only one instance of a class can exist, and provide an easy, global way to access it. Some classes in a domain should only ever have one instance, for example a Printer Spooler class that handles print requests and sends them to Printers. A global variable could be used, but this is [[No global variables|bad design]] and doesn't stop multiple instances being created.
+
[[Category:Design Patterns]]
 +
[[Category:Creational Patterns]]
 +
Singleton is a simple design pattern to ensure that only one instance of a class can exist, and provide an easy, global way to access it. Some classes in a domain should only ever have one instance, for example a Printer Spooler class that handles print requests and sends them to Printers. A global variable could be used, but this is [[No Global Variables|bad design]] and doesn't stop multiple instances being created.
  
 
The Singleton pattern makes the class itself responsible for ensuring only one instance exists.
 
The Singleton pattern makes the class itself responsible for ensuring only one instance exists.
Line 13: Line 15:
  
 
Singleton defines an instance() method through which clients can access the unique instance. If an instance doesn't exist, it creates one before returning it. The constructor is private, ensuring only one instance can be created. The $ signs mean "static."
 
Singleton defines an instance() method through which clients can access the unique instance. If an instance doesn't exist, it creates one before returning it. The constructor is private, ensuring only one instance can be created. The $ signs mean "static."
 
== Note ==
 
 
The Singleton pattern can be used in the [[Abstract Factory]] pattern.
 
  
 
== Recognising the pattern ==
 
== Recognising the pattern ==
Line 24: Line 22:
 
* private static attribute to hold uniqueInstance of itself.
 
* private static attribute to hold uniqueInstance of itself.
 
* concrete public static getInstance() method.
 
* concrete public static getInstance() method.
 +
 +
==Consequences==
 +
* The Singleton pattern allows you to control the access to the single instance, including how and when it can be accessed.
 +
* The Singleton pattern is better than using global variables since the name space is not polluted with global variable names.
 +
* The Singleton class can be subclassed to configure an application with the subclass.
 +
* The Singleton pattern allows you to easily change the number of allowable instances of the class to more than one. You will only need to change the method that gives clients access to the Singleton instance.
 +
* Singleton is a better solution than using static because it allows you to change it to allow several instances, something that is difficult to do using static.
 +
 +
== Example ==
 +
 +
You can find [http://java.dzone.com/articles/design-patterns-singleton here] a nicely explained java code example of the Singleton Pattern usage in the real world.
  
 
== Risks of Singleton ==
 
== Risks of Singleton ==
Line 32: Line 41:
  
 
* The assumption that only one instance will ever be required can be shortsighted. For example, one may have a Settings object as a singleton. But if one later wishes to extend the software to run multiple objects each with their own Settings instance, much painstaking refactoring will be required.
 
* The assumption that only one instance will ever be required can be shortsighted. For example, one may have a Settings object as a singleton. But if one later wishes to extend the software to run multiple objects each with their own Settings instance, much painstaking refactoring will be required.
* If you're using the static nature of the pattern to avoid passing around many references, it's a sign you might be overusing that class, and not following the maxim of [[Tell, don't ask]]. Possibly you have a [[Avoid god classes|God class]]. It's a sign that you should at least think about restructuring the code to reduce dependence on this class.
+
* If you are using the static nature of the pattern to avoid passing around many references, it may be a sign you are overusing that class, and not following the maxim of [[Tell, don't ask]]. Possibly you have a [[Avoid god classes|God class]]. It is a sign that you should at least think about restructuring the code to reduce dependence on this class.
* You don't need a Singleton to make use of [[Use lazy initialization pattern|lazy initialization]]. If you're using a Singleton just for this, then you definitely need to get rid of it.
+
* You do not need a Singleton to make use of [[Use lazy initialization pattern|lazy initialization]].
 +
 
 +
== Related Patterns ==
 +
Many patterns can be implemented using the Singleton pattern. See [[Abstract Factory]], [[Builder]], and [[Prototype]].
  
 
== See also ==
 
== See also ==
 
* [[Design patterns]]
 
* [[Design patterns]]
* [[No global variables]]
+
* [[Beware singletons]]
* [[Abstract Factory]]
+
 
 +
{{design patterns}}

Latest revision as of 03:23, 25 November 2010

Singleton is a simple design pattern to ensure that only one instance of a class can exist, and provide an easy, global way to access it. Some classes in a domain should only ever have one instance, for example a Printer Spooler class that handles print requests and sends them to Printers. A global variable could be used, but this is bad design and doesn't stop multiple instances being created.

The Singleton pattern makes the class itself responsible for ensuring only one instance exists.

Contents

Use when

  • There must be only one instance of a class and it must be easily accessible to clients.
  • When the class needs to be extensible, and clients should be able to use a derived class without changing their code.

Structure

SingletonStructure.png

Singleton defines an instance() method through which clients can access the unique instance. If an instance doesn't exist, it creates one before returning it. The constructor is private, ensuring only one instance can be created. The $ signs mean "static."

Recognising the pattern

Classes: Singleton.

  • private constructor.
  • private static attribute to hold uniqueInstance of itself.
  • concrete public static getInstance() method.

Consequences

  • The Singleton pattern allows you to control the access to the single instance, including how and when it can be accessed.
  • The Singleton pattern is better than using global variables since the name space is not polluted with global variable names.
  • The Singleton class can be subclassed to configure an application with the subclass.
  • The Singleton pattern allows you to easily change the number of allowable instances of the class to more than one. You will only need to change the method that gives clients access to the Singleton instance.
  • Singleton is a better solution than using static because it allows you to change it to allow several instances, something that is difficult to do using static.

Example

You can find here a nicely explained java code example of the Singleton Pattern usage in the real world.

Risks of Singleton

The Singleton design pattern has several apparent advantages. The programmer can be sure that only one instance will exist. That instance is static. This saves the mess of having to pass around many references to the object. Also, lazy initialization is an inherent part of the pattern, which can improve performance.

However, these advantages can tempt the programmer to make unwise design decisions.

  • The assumption that only one instance will ever be required can be shortsighted. For example, one may have a Settings object as a singleton. But if one later wishes to extend the software to run multiple objects each with their own Settings instance, much painstaking refactoring will be required.
  • If you are using the static nature of the pattern to avoid passing around many references, it may be a sign you are overusing that class, and not following the maxim of Tell, don't ask. Possibly you have a God class. It is a sign that you should at least think about restructuring the code to reduce dependence on this class.
  • You do not need a Singleton to make use of lazy initialization.

Related Patterns

Many patterns can be implemented using the Singleton pattern. See Abstract Factory, Builder, and Prototype.

See also


Personal tools