It is imperative to ensure atomicity (indivisible-ness) for certain "master" objects in your applications.
Some examples of Singleton:
If your program somehow winds up with 2 globally-scoped objects of a class that handles bank deposits, let's hope our account gets updated by the one with a larger dollar amount!
In Java, there is a single instance of java.lang.Runtime. If there were more than 1 language instance to interface with the Java application environment, you can see how problems would unfold.
In .NET applications, an application .config file serves as a single source of configuration values.
Log Managers should have 1 and only 1 instance, lest our log files become far too complex to sift through when we are tracking down an application issue.
Reference: https://stackoverflow.com/questions/3192095/where-exactly-the-singleton-pattern-is-used-in-real-application
Singleton ensures the existence of 1 and only 1 object instance (or version/representation) of an application entity- at all times.
Some examples of Singleton:
If your program somehow winds up with 2 globally-scoped objects of a class that handles bank deposits, let's hope our account gets updated by the one with a larger dollar amount!
In Java, there is a single instance of java.lang.Runtime. If there were more than 1 language instance to interface with the Java application environment, you can see how problems would unfold.
In .NET applications, an application .config file serves as a single source of configuration values.
Log Managers should have 1 and only 1 instance, lest our log files become far too complex to sift through when we are tracking down an application issue.
Reference: https://stackoverflow.com/questions/3192095/where-exactly-the-singleton-pattern-is-used-in-real-application
