Where exactly the Singleton Pattern is used in real application?

Question

I was just curious where exactly the singleton pattern is used... I know how the pattern works and where it can be used but i personally never used in any real application. Can

Answer 1

When you use Logger, you use Singleton pattern for the Logger class. In case it is not Singleton, every client will have its own Logger object and there will be concurrent access on the Logger instance in Multithreaded environment, and multiple clients will create/write to the Log file concurrently, this leads to data corruption.

Answer 2

Typically singletons are used for global configuration. The simplest example would be LogManager - there's a static LogManager.getLogManager() method, and a single global instance is used.

In fact this isn't a "true" singleton as you can derive your own class from LogManager and create extra instances that way - but it's typically used as a singleton.

Another example would be java.lang.Runtime - from the docs:

Every Java application has a single instance of class Runtime that allows the application to interface with the environment in which the application is running. The current runtime can be obtained from the getRuntime method.

That's pretty much the definition of a singleton :)

Now the singleton pattern is mostly frowned upon these days - it introduces tight coupling, and makes things which use the singleton harder to test, as you can't easily mock out that component. If you can get away without it, so much the better. Inject your dependencies where possible instead.

Answer 3

Singleton pattern is generally useful when the object that is created once and shared across different threads/Applications. Consider the case that you are implementing the properties load class for a printer.

Now Printers can be of variant properties. For eg:- Mono Printer, Color Printer, Automatic Scanner Support Printer and so on...

Every time on boot this config file has to load to enable a few buttons/ applications on the UI say tab or any Printer UI.

The value of the supported features are stored in form of a config table like say 1 if feature supported and 0 if not supported.

Based on the supported features we enable disable certain functionalities and application on the UI. Now this config file location in case of printers manufactured by a single company are always stored at a fixed path.

The file values would change/would be read only in the following scenarios:- 1. On Boot. 2. on Addition or deletion of any new hardware peripheral.

We can use a singleton class to implement the reading of configuration files. As the same values i.e. the config does not change on UI intervention and can be changed only on hardware intervention.

This is one example I can think of where we can implement Singleton design pattern.

Answer 4

Singleton Class is basically used when you have to allow only single instantiation of the class. Taking real world example, In case of OOP designing of a library, we can create library class as singleton class.

Answer 5

Consider the situation of AudioDriverService which is designed in Singleton Pattern. So we are allowed to create just a single instance of AudioDriverService class. Now actually your Windows Media Player or Youtube Player both will share the same object of AudioDriverService rather than creating a new instance.

Answer 6

Singleton is a nice design pattern. Before deciding on the pattern first do an in depth analysis of your problem and the solution. If in your solution some object has only one instance and you want to model that in your design then you should use singleton pattern. For example if you are modelling a PC in the software there can be only one instance of a PC with respect to your running program. As Jon Skeet said java.lang.Runtime is modelled as a singleton because for all the java objects that are loaded and running inside a java runtime there is only one instance of runtime.

Again lot of times it is used for the wrong reasons. Never create a singleton so that you can easily access the object (like Object::instance() ) from anywhere without passing the object around. The is the worst use I have ever come across.