Singleton Pattern#

The Singleton Pattern, also known as the Singleton, Monostate, or Mono pattern, belongs to the category of creational patterns. It involves a single class that is responsible for creating the required object while ensuring that only a single object is created. This class provides a way to access its unique object, ensuring that the accessed object is an instance of the class created only once.

Description#

The Singleton Pattern ensures that a class has only one instance, and it instantiates itself and provides this instance to the entire system. This class is known as a singleton class, offering a method of global access. The main points of the Singleton Pattern are that a class can only have one instance, it must create this instance by itself, and it must provide this instance to the entire system by itself.

Pattern structure#

• Singleton: Singleton.
• Proxy: Singleton creation proxy.

Advantages#

• Provides controlled access to the unique instance. Since the singleton class encapsulates its unique instance, it can strictly control how and when clients access it, providing a shared concept for design and development teams.
• Since only one object exists in the system memory, it can conserve system resources. For objects that need to be created and destroyed frequently, the Singleton Pattern undoubtedly enhances system performance.
• Allows a variable number of instances. We can extend based on the Singleton Pattern, using methods similar to singleton control to obtain a specified number of object instances.

Disadvantages#

• Due to the lack of an abstraction layer in the Singleton Pattern, extending the singleton class is quite difficult.
• The singleton class is overly responsible, to some extent violating the single responsibility principle. Because the singleton class acts as both a factory role, providing factory methods, and a product role, containing some business methods, it integrates the creation of the product and the product's functionality.
• Misusing the singleton can lead to negative issues. For example, designing the database connection pool object as a singleton class to save resources may cause an overflow of shared connection pool objects in the program. Additionally, many object-oriented languages' runtime environments provide automatic garbage collection, so if an instantiated object is not used for a long time, the system will consider it garbage, automatically destroying and reclaiming resources. When it is used again, it will be reinstantiated, resulting in loss of object state.

Implementation#

For ES6, simply exporting export default new Singleton() can export the object as a singleton. However, the current ES6 module is static and cannot achieve on-demand loading. Of course, it can be parsed using babel, and CommonJS's require can also be used. Moreover, a new specification proposal may incorporate dynamic loading into the standard. Below is the Singleton Pattern implemented using a proxy and lazy loading.

class Singleton{
    constructor(){
        this.name = "singleton";
    }
}

class ProxyCreateSingleton{
    static getInstance(){
        if(this.instance) return this.instance;
        return (this.instance = new Singleton);
    }
}

(function() {
    var instance1 = ProxyCreateSingleton.getInstance();
    var instance2 = ProxyCreateSingleton.getInstance();
    console.log(instance1 === instance2); // true
    console.log(new Singleton() === new Singleton()); // false
})();

Daily Question#

References#