Singleton Pattern con Javascript
En mi artículo anterior ya os hable de que eran los patrones de diseño y hoy con este artículo os quiero presentar al primer patrón de esta serie sobre Patrones de diseño: el Singleton Pattern.
Este patrón pertenece a la categoría de los patrones creacionales. La principal misión de este patrón es la de crear una sola instancia de una clase y que este disponible para el resto de la aplicación.
Este patrón pertenece a la categoría de los patrones creacionales
🤬 Inconvenientes de este patrón
A parte de que es raro de por si que necesites usar este patrón porque la verdad que no tiene nada de malo tener al menos la posibilidad de crear más de una instancia de una clase como veremos más adelante… hay quien piensa que este patrón es un gran “code smell” pues es considerado por muchos una mala práctica.
Una de las razones por las que un Singleton es una mala práctica, es porque generalmente se expone la instancia de nuestro objeto al contexto global de la aplicación, por lo que pudiera ser modificada en cualquier momento perdiendo el control de la misma.
Los Singleton además se saltan el principio de Single Responsability de SOLID pues estamos utilizando una clase para controlar que solo una instancia sea creada además del código para el cometido principal que debe desempeñar dicha instancia en nuestra aplicación.
Además, mantienen el estado a lo largo de toda la vida de la aplicación por lo que podría ser un recolector de basura perfecto y comerse la memoria de nuestro sistema.
Hacer unit test con ellas puede llegar a ser un infierno ¿Por qué? Porque cada test debe ser totalmente independiente al anterior y eso no se cumple, por lo que al mantener el estado la aplicación se hace difícil de testear.
🔧 Implementación del patrón Singleton
Ahora que os he quitado las ganas de utilizar este patrón 😂 Os voy a contar en qué consiste y por supuesto con Javascript 🥰(lo prometido es deuda).
Implementar el patrón Singleton es muy fácil comparado con lenguajes como Java en el que se usan métodos estáticos y demás aburrido “Java stuff” 😣
Es tan sencillo como que en el constructor de nuestra clase Singleton comprobemos sí existe una instancia de su clase.
Si la instancia existe la devolvemos directamente y si no existe creamos una nueva instancia de la clase y la devolvemos ¿Sencillo verdad?
Ya el resto del código de nuestra clase sería el código qué necesitemos escribir para que nuestra instancia del Singleton haga la función que necesitemos que desempeñe el Singleton en nuestra aplicación.
Veámoslo mejor en un ejemplo ya entrando en materia con código Javascript:
Imagina que necesitamos crear una oficina, UNA SOLA OFICINA para una empresa determinada. Como veis primero estamos comprobando que Office.instance no sea undefined y en caso de serlo le pasamos el contexto this a la instancia y lo devolvemos.
En este código crearíamos un primer objeto office1 con los datos de nuestra oficina pero ¿Qué pasaría al intentar crear el segundo objeto?
Que volvería a devolvernos la primera instancia creada de nuestra clase Office. ¿Lo veis? Ya tenemos implementado nuestro Singleton.
¿Qué pasa si en un futuro necesitamos una segunda oficina?
Que nuestro Singleton se hace inútil. Es por eso que comentaba más arriba no tiene nada de malo tener al menos la posibilidad de crear más objetos de una clase aunque en realidad necesitemos un solo objeto. Por eso para implementar este patrón tienes que estar muy seguro, 100% seguro de que solo vas a necesitar una instancia para toda la aplicación.
No tiene nada de malo tener al menos la posibilidad de crear más objetos de una clase aunque en realidad necesitemos un solo objeto
Gracias por haber llegado hasta aquí y nos vemos en el siguiente artículo acerca de patrones con Javascript en el que explicaré el patrón Buider.
Por cierto, si veis que algo de lo que explico no es correcto hacédmelo saber, aprendo mucho de cada uno de vosotros ☺️
¡Espero que os sirva, muchas gracias y nos vemos en el siguiente!
