- Summary
- This pattern Restrict the class from creating more than one instance.
- Best approach is to use Static Constructor for creating instance then a property to get the instance
- If using IOC Containers like Unity in your project then use them for singleton creation in declarative way.
- As much as possible avoid using Instance based singletons.
- Overview Tutorials
- http://www.oodesign.com/singleton-pattern.html
- When to Use
- Singletons are generally used in situation like window
manager, connection manager, Loggers, Class
Loaders, Load Balancers, and Factories.
- Singleton Types
- Broadly classifying there are two types of singleton object (from behavior point of view),
- Early Instantiation
- Lazy Instantiation
- In most of cases early Instantiation is preferred because of
being thread safe and minimal overhead .
- Implementation Approaches
- By Using Static Constructor and Lazy Instantiation (Best Pick as per Jeff/MSDN)
- By Using Static Function
- Multithreaded Lazy Instantiation with double checked locking (Second Best Pick)
- Early Instantiation [Thread Safe in .Net]
- Static Instantiation (Lazy Instantiation) [Thread unsafe]
- By Using Property (MSDN Recommended)
- By Using Instance Function and Static Object Reference.(Classical Approach)
- By Using IOC Containers
- Singleton can also be implemented using IOC Containers like Unity that provides built-in mechanism for creating singleton without modify existing code
- Special Considerations
- Synchronization Issues
- It faces “Reader Writer Issue” that can be mitigated by
using ‘volatile’ keywords and Double
Locking or Double Checked Locking.
- Deadlock Issues
- Instead of locking
whole class use a dedicated variable for locking
- Issue of Multiple Class Loaders
- 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
- Inhering a Singleton class
- Inherited class will not be singleton so it is Not Suggested.
- Static Vs Singleton
- I would prefer to use singleton if State is to be maintained
and Instance need to be passed as parameter
- Static is preferable if call is
not maintaining any state and all the
method are instance independent
- MSDN Community also recommends Static over singleton because of less complexity
- Double Checked Vs Type Constructor bases Lazy Loading
- I would prefer static lazy loading by declaring a class
constructor and then initializing the object in static contractor by calling
private instance constructor.
- Singletons`s Downside
- 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.
- 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.
- 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.
- 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.
- 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.
- References
- http://www.oodesign.com/singleton-pattern.html
- http://www.ibm.com/developerworks/java/library/j-dcl/index.html
- http://msdn.microsoft.com/en-us/library/ff650316.aspx
- http://tech.puredanger.com/2007/07/03/pattern-hate-singleton/
- http://misko.hevery.com/2008/08/25/root-cause-of-singletons/
|
|