Adding initialization-on-demand idiom and noninstantiable class instead of interface constant idiom
layout, title, folder, permalink, pumlid, categories, tags
layout | title | folder | permalink | pumlid | categories | tags | |||
---|---|---|---|---|---|---|---|---|---|
pattern | Singleton | singleton | /patterns/singleton/ | HSV14SCm20J0Lk82BFxf1ikCh0n26ZZizfDVVhjRjwfvIhg-Bc35cyZvAQtZoYD3l4w364gTWxhcms2d3z-ydnAzsRuO4BUWmV43HRUcWcaagF-Lz55M3lq2 | Creational |
|
Intent
Ensure a class only has one instance, and provide a global point of access to it.
Applicability
Use the Singleton pattern when
- there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point
- when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code
Typical Use Case
- the logging class
- managing a connection to a database
- file manager
Real world examples
Consequences
- Violates Single Responsibility Principle (SRP) by controlling their own creation and lifecycle.
- Encourages using a global shared instance which prevents an object and resources used by this object from being deallocated.
- Creates tightly coupled code that is difficult to test.
- Makes it almost impossible to subclass a Singleton.