El patrón de módulo de JavaScript es otra forma común de organizar el código en sus aplicaciones de JavaScript. De hecho, fue Doug Crockford quien llamó por primera vez la atención generalizada sobre este patrón y, hasta el día de hoy, sigue siendo de uso generalizado en el ecosistema JavaScript. Al igual que en nuestro tutorial de patrones de prototipos, en este artículo veremos qué es lo bueno y lo malo del patrón del módulo además de su estructura general. Una vez que esté familiarizado con este patrón, es probable que lo detecte en muchas bibliotecas de JavaScript de código abierto populares disponibles actualmente.


El reclamo de la fama del patrón modular

Cuando está programando en un lenguaje orientado a objetos que ofrece palabras clave específicas para permitir la encapsulación como publicprivateprotected, deja muy claro cómo diseñar un programa y configurar la visibilidad adecuada de varias propiedades y métodos de objetos. JavaScript no tiene estas palabras clave, por lo que podría pensar que no tiene suerte en este sentido. Resulta que puede aproximar esta funcionalidad haciendo uso del Patrón de módulo, donde esta funcionalidad está determinada por el patrón en sí en lugar de prefijar palabras clave específicas. Para los programadores de programación orientada a objetos más tradicionales, esto será música para sus oídos. Para otros, puede que no sea tan importante si ya tienen su propia forma de lidiar con la naturaleza infinitamente flexible de JavaScript.

Un inconveniente del patrón del módulo

El patrón del módulo es genial y todo, pero tiene un par de inconvenientes. La primera es que no es eficiente en la memoria como lo es el patrón prototipo que vemos. Recuerde que cuando usamos el patrón prototipo, cada función se carga en la memoria solo una vez. Con el patrón de módulo, este no es el caso. Cada vez que se crea un nuevo objeto a través de su módulo, se carga en la memoria una nueva copia de cualquier función de ese módulo. Si tiene un módulo con 10 funciones y crea 10 nuevas instancias de ese objeto, ahora tiene 100 funciones cargadas en la memoria. Para ser justos, la capacidad de JavaScript para optimizar el tiempo de ejecución mitigará cualquier problema de rendimiento que pueda ver, pero vale la pena señalar que esta es una diferencia significativa entre el patrón del prototipo y el patrón del módulo. Un segundo inconveniente del patrón es que se pierde la funcionalidad de extensión y anulación en el módulo, ya que ya no utilizamos el patrón de creación de prototipos. Además, a medida que algunos miembros se vuelven privados y de alcance oculto, algunos desarrolladores sienten que las cosas se vuelven más difíciles de depurar. Una vez más, es cuestión de aprender todos estos patrones diferentes, y luego puede elegir su veneno como mejor le parezca. Resumamos los pros y los contras.

Pros

  • Capacidad para modularizar scripts en objetos reutilizables
  • Las variables y funciones se eliminan del ámbito global
  • Capacidad para implementar métodos privados y exponer métodos públicos según sea necesario

Contras

  • Las funciones se duplican en muchos objetos en la memoria
  • Difícil de extender y anular
  • Agrega complejidad de depuración

La estructura del patrón del módulo JavaScript

Hay algunas cosas a tener en cuenta sobre este patrón. La primera es que vemos que aplicamos mayúsculas al nombre del objeto cuando definimos el módulo. Esta es una convención para indicar que deberíamos usar la newpalabra clave cuando vayamos a hacer uso de este módulo en nuestro código en un momento posterior. La primera sección dentro de la función anónima que tenemos es donde residirían las variables y funciones privadas. Dentro de la función anónima, podemos ver una returndeclaración que devuelve un objeto literal. Todo lo contenido en este objeto devuelto será público. Sin ser demasiado sofisticado, podemos resumir el patrón en tres secciones principales.

Secciones del patrón del módulo

  • El constructor (el objeto del módulo con nombre y la asignación de función, pueden o no tomar parámetros)
  • El área de miembros privados (todo lo que viene antes de la returnpalabra clave)
  • El área pública devuelta por el objeto literal (cualquier cosa en el objeto devuelto es pública)

Con eso, veamos ahora una demostración de ejemplo real de este patrón.

Hacer clic Claro

Tenga en cuenta que con el patrón del módulo no tenemos acceso a los miembros privados del módulo directamente.


Resumen del patrón del módulo de JavaScript

En este tutorial sobre el patrón de módulo de JavaScript, hemos visto cómo el patrón de módulo se puede utilizar para proporcionar encapsulación que conduce a una mejor reutilización del código, un mantenimiento más fácil y la eliminación de variables y funciones fuera del alcance global. En nuestro estudio de los patrones de JavaScript hasta ahora, el patrón del módulo es el primero que proporciona visibilidad pública y privada para nuestras variables y funciones, y esa es una gran característica cuando no desea que las personas que llaman al módulo puedan acceder funciones o variables. Como comentamos, cada instancia que crea cuando usa el patrón de módulo duplica las diferentes funciones que define en la memoria, a diferencia del patrón de prototipo que es más eficiente en memoria. También vimos que extender y anular ya no es una opción.