|
2 | 2 |
|
3 | 3 | Ensure a class has only one instance, and provide a global point of access to it. |
4 | 4 |
|
| 5 | +## Problem |
| 6 | + |
| 7 | +* How can it be ensured that a class has only one instance? |
| 8 | +* How can the sole instance of a class be accessed easily? |
| 9 | +* How can a class control its instantion? |
| 10 | +* How can the number of instances of a class be restricted? |
| 11 | + |
| 12 | +## Solution |
| 13 | + |
| 14 | +* Hide the constructor of the class |
| 15 | +* Define a public static operation `getInstance()` that returns the sole instance of the class. |
| 16 | + |
| 17 | +## Common Structure |
| 18 | + |
| 19 | + |
| 20 | + |
| 21 | +* Singleton |
| 22 | + * declares static method `getInstance` that should return the same instance of `Singleton` class. |
| 23 | + * may be responsible for creating its own unique instance. |
| 24 | + |
| 25 | +## Collaboration |
| 26 | + |
| 27 | +* Clients access a Singleton instance solely through static `getInstance()` method. |
| 28 | + |
| 29 | +## Benefits |
| 30 | + |
| 31 | +* Ensures that class has only a single instance. |
| 32 | +* Provides global access point to that instance. |
| 33 | +* Allows deferred initialization |
| 34 | + |
| 35 | +## Drawbacks |
| 36 | + |
| 37 | +* Violate single responsibility principle |
| 38 | + * They control their own creation and lifecycle. |
| 39 | +* instance is tightly coupled to Singleton class => Difficult to test |
| 40 | +* Requires special treatment in a multithreaded environment. |
| 41 | + |
| 42 | +## Example |
| 43 | + |
| 44 | +There are two ways to implement singleton. |
| 45 | + |
5 | 46 |  |
6 | 47 |
|
7 | | -## Static Initialization |
| 48 | +### Static Initialization |
8 | 49 |
|
9 | 50 | :thumbsup: **You may want to create your Singleton eagerly**, if |
10 | 51 | * your application always creates and uses an instance of the `Singleton` |
@@ -34,7 +75,7 @@ The class is marked as **sealed** to prevent derivation, which could add instanc |
34 | 75 |
|
35 | 76 | Because the **Singleton** instance is referenced by a private static member variable, the instantiation does not occur until the class is first referenced by a call to the **Instance** property. This solution therefore implements a form of the lazy instantiation property, as in the Design Patterns form of Singleton. |
36 | 77 |
|
37 | | -## Multithreaded Singleton |
| 78 | +### Multithreaded Singleton |
38 | 79 |
|
39 | 80 | :thumbsup: **Use double-checked locking**, if |
40 | 81 | * you want to keep separate threads from creating new instances of the singleton at the same time (thread-safe) |
@@ -75,5 +116,10 @@ Lastly, this approach uses a **syncRoot** instance to lock on, rather than locki |
75 | 116 |
|
76 | 117 | This double-checked locking approach solves the thread concurrency problems while avoiding an exclusive lock in every call to the instance propery method. It also allows you to delay instantiation until the object is first accessed. |
77 | 118 |
|
| 119 | +## Relations with Other Patterns |
| 120 | + |
| 121 | +* **AbstractFactory*, **Builder**, **Prototype** - These patterns can be implemented using the Singleton pattern |
| 122 | +* **Flyweight** - There should be only one Singleton instance, whereas Flyweight class can have multiple instances with a different intrinsic state. Whatsmore, Singleton object can be mutable but Flyweight objects are immutable. |
| 123 | + |
78 | 124 | Reference: |
79 | 125 | * MSDN - [Implementing Singleton in C#](https://msdn.microsoft.com/en-us/library/ff650316.aspx) |
0 commit comments