1.Topics‎ > ‎Architecture‎ > ‎Patterns‎ > ‎a.Design Patterns‎ > ‎B.Creational Patterns‎ > ‎

A.Singleton Pattern

  1. Summary
    1. This pattern Restrict the class from creating more than one instance.
    2. Best approach is to use Static Constructor for creating instance then a property to get the instance 
    3. If  using IOC Containers like Unity in your project then use them for singleton creation in declarative way.
    4. As much as possible avoid using Instance based singletons.
  2. Overview Tutorials 
    1. http://www.oodesign.com/singleton-pattern.html
  3. When to Use 
    1. Singletons are generally used in situation like window manager, connection manager, Loggers, Class Loaders, Load Balancers, and Factories.
  4. Singleton Types 
    1. Broadly classifying there are two types of singleton object (from behavior point of view), 
      1. Early Instantiation
      2. Lazy Instantiation
    2. In most of cases early Instantiation is preferred because of being thread safe and minimal overhead .
  5. Implementation Approaches
    1. By Using Static Constructor and Lazy Instantiation (Best Pick as per Jeff/MSDN) 
    2. By Using Static Function 
      1. Multithreaded Lazy Instantiation with double checked locking (Second Best Pick) 
      2. Early Instantiation [Thread Safe in .Net] 
      3. Static Instantiation (Lazy Instantiation) [Thread unsafe] 
    3. By Using Property (MSDN Recommended) 
    4. By Using Instance Function and Static Object Reference.(Classical Approach)
    5. By Using IOC Containers
      1. Singleton can also be implemented using IOC Containers like Unity that provides built-in mechanism for creating singleton without modify existing code 
  6. Special Considerations
    1. Synchronization Issues
      1. It faces “Reader Writer Issue” that can be mitigated by using ‘volatile’ keywords and Double Locking or Double Checked Locking.
    2. Deadlock Issues
      1.  Instead of locking whole class use a dedicated variable for locking
    3.  Issue of Multiple Class Loaders
      1. If singleton is loaded by two different loader (particularly happens in Java) then two different instance will be created. We can use kernel level synchronization object in this case
    4. Inhering a Singleton class
      1. Inherited class will not be singleton so it is Not Suggested.
    5. Static Vs Singleton
      1. I would prefer to use singleton if State is to be maintained and Instance need to be passed as parameter 
      2. Static is preferable if call is not maintaining   any state and all the method are instance independent
      3. MSDN Community also recommends Static over singleton because of less complexity 
    6. Double Checked Vs Type Constructor bases Lazy Loading
      1. I would prefer static lazy loading by declaring a class constructor and then initializing the object in static contractor by calling private instance constructor. 
  7. Singletons`s Downside
    1. Hides dependencies – A component that uses one or more singletons is hiding crucial information about your dependencies. It doesn’t take long for calls to a singleton to creep through your code base like kudzu, slowly attaching itself to every class in the system. Exposing that dependency forces you to think about it as you use a component. It also makes it more reusable as the caller can understand its requirements and how they might be satisfied.
    2. Hard to test – The hidden coupling of users on a singleton makes testing a nightmare as there is no way to mock out or inject a test instance of the singleton. Also, the state of the singleton affects the execution of a suite of tests such that they are not properly isolated from each other.
    3. Hard to subclass – Since initialization occurs in a singleton in static code, it is not amenable to subclassing because subclasses inherit the initialization code without the chance to override it.
    4. It’s a lie! (in most Java systems JAVA 1.4 and below) – Singletons in Java are based on static variables, which are held per-classloader, not per-VM. In most systems of any complexity these days (any based on an app server, OSGi, Eclipse, plugins, etc) many classloaders will be involved. In that case, it is quite easy for two plugins to create their own instance of a singleton. Sometimes this is done by design and is desirable. But it’s also easy to screw up. It’s also usually critical that the singleton get created in the right classloader, which can make lazily constructing the singleton tricky.
    5. A singleton today is a multiple tomorrow – It’s not at all unusual to discover that you now need 2 or more of something you previously only needed one of. Hard-coding the singleton pattern into your code makes it impossible to satisfy that demand later. This probably seems really weird if it hasn’t happened to you, but it has happened more than once to me.
  8. References
    1.  http://www.oodesign.com/singleton-pattern.html
    2. http://www.ibm.com/developerworks/java/library/j-dcl/index.html
    3. http://msdn.microsoft.com/en-us/library/ff650316.aspx
    4.  http://tech.puredanger.com/2007/07/03/pattern-hate-singleton/
    5.  http://misko.hevery.com/2008/08/25/root-cause-of-singletons/