Patrón Singleton

0
348
patrón singleton

Índice de contenidos

  1. Introducción
  2. ¿Qué es un patrón de diseño?
  3. Patrón Singleton
  4. ¿Antipatrón?
  5. Conclusión

Introducción

En este articulo te voy a explicar en uno de los patrones de diseño de software más conocidos, el patrón Singleton. Te voy a explicar en que consiste y como aplicarlo. Asi que vamos a ello:

¿Qué es un patrón de diseño?

En 1994 los llamados Gang of Four (GoF) publicaron un libro llamado Design Patterns, es a partir de este libro que se inició el concepto de patrón de diseño en el desarrollo de software.

Los patrones de diseño son soluciones habituales a problemas comunes en el mundo del desarrollo de software. Para que se considere un patrón de diseño, este debe ser general y reutilizable. Existen tres categorías principales: Patrones creacionales, estructurales y de comportamiento. Este caso vamos a ver el patrón Singleton que es un patrón creacional ya que proporciona un mecanismo para la creación de objetos.

Patrón Singleton

Un Singleton es una clase que se instancia una única vez y a la que se puede acceder de manera global. Esa instancia va a ser compartida por toda la aplicación. Este patrón debe utilizarse cuando sabes que la clase debe tener una única instancia o se necesite un control estricto de una variable global

Vamos a ver paso por paso como transformar una clase normal de TypeScript a un Singleton:

class Singleton {
	
	constructor(){}
	
	public doSomething() {
	// ....
	}
}

Tenemos la clase Singleton, una clase normal y corriente que puede tener mas de una instancia, lo comprobamos:

comparación de instancias

Aquí podemos ver que la clase aún no sigue los requisitos para ser un singleton. Lo primero que vamos a hacer es crear un método estático para que sea accesible sin necesidad de crear una instancia, el cual nos devuelva la instancia del singleton en caso de que esta exista o la cree en caso de que no.

class Singleton {
  private static instance: Singleton;

  constructor() { }
    
  public static getInstance(): Singleton {
    if (!Singleton.instance) {
      Singleton.instance = new Singleton();
    }
      return Singleton.instance;
  }

  public doSomething() {
	// ....
	}
}

Si ahora comprobamos las instancias de la misma manera que antes, comprobamos que ahora, si que estamos utilizando la misma instancia:

comparación de instancias

Pero aún así, nos queda una última cosa. Es necesario cambiar el constructor a privado, para evitar que se puedan crear nuevas instancias con el new .

class Singleton {
  private static instance: Singleton;

  private constructor() { }
    
  public static getInstance(): Singleton {
    if (!Singleton.instance) {
      Singleton.instance = new Singleton();
    }
      return Singleton.instance;
  }

  public doSomething() {
	// ....
	}
}

¿Antipatrón?

Pese a las ventajas que nos ofrece el patrón Singleton como la certeza de que existe una única instancia, consistencia del estado o la facilidad para la gestión de recursos compartidos. El patrón Singleton es considerado por muchos como un antipatrón y se desaconseja su uso, veamos algunos de los motivos:

  • Viola la S de SOLID (Single Responsability Principle). Una clase singleton tiene 2 responsabilidades, asegurarse de que no se instancia mas de una clase y su responsabilidad natural.
  • Difícil de testear. Testear un singleton puede ser tedioso ya que nos limita a la hora de generar instancias para los tests. Además en muchos casos habría que ir eliminando las instancias creadas para que no afecten al test siguiente.
  • Alto acoplamiento. El uso de singletons puede crear un fuerte acoplamiento entre las clases y el singleton, perjudicando así la mantenibilidad del código.
  • Concurrencia. Los singletons pueden generar problemas al trabajar con hilos.

Algo que tenemos que tener en cuenta es que estos problemas se reducen bastante cuando utilizamos conjuntamente el patrón Singleton con la inyección e inversión de dependencias. Ya que estas facilitan el testing y reducen el acoplamiento. Por eso es aconsejable utilizar estos patrones y principios en conjunto para obtener todos sus beneficios.

Es muy común que los contenedores de inyección de dependencias utilicen singletons debido a la eficiencia, el rendimiento, la consistencia del estado y la simplicidad y facilidad para su gestión.

Conclusión

El patrón Singleton es uno de los patrones más conocidos y utilizados en la industria del software. Como hemos visto en este articulo, nos aporta una serie de beneficios pero también nos perjudica en ciertos aspectos. Mi recomendación es que a la hora de utilizar un singleton, evalúes la necesidad de este e intentes utilizarlo de la mano de otros patrones como la inyección de dependencias y el principio de inversión de dependencias para maximizar los beneficios.

Muchas gracias por tu atención. 😊

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad