Cuando hablamos de JavaScript, ¿qué significa acoplamiento y desacoplamiento?

(Primer pensamiento en “explicar como a un niño de diez años: https://xkcd.com/1364/)

La versión corta es que el acoplamiento implica tener al menos dos piezas de código separadas que dependen unas de otras. El desacoplamiento es el acto de eliminar tal dependencia.

Un ejemplo que viene a mi mente es un proyecto en el que estoy trabajando en mi pasantía. Estamos reconstruyendo aplicaciones antiguas como aplicaciones web utilizando la interfaz de usuario de Telerik Kendo. La configuración común para estas aplicaciones son: Cuadrícula que contiene filas de datos, Ventana que contiene un formulario que se puede usar para agregar o editar una fila de datos. La forma en que se había configurado anteriormente era con MUCHO código duplicado.

Digamos que el proyecto tiene tres cuadrículas. Cada cuadrícula se inicializa en algún momento, con todo igual excepto por una ID de elemento diferente y un par de cosas más. El código se copió en cada uno, dejando tres lugares para cambiar una cosa con todas las cuadrículas. Fue un desastre.

gridOne.initGridOne = function () {
// código aquí
}

gridTwo.initGridTwo = function () {
// código copiado aquí
}

gridThree.initGridThree = function () {
// código copiado aquí también
}

De todos modos, cada cuadrícula tiene botones Agregar y Editar que abren la ventana para el formulario de esa cuadrícula en particular. Esta es una forma de acoplamiento, donde la cuadrícula 1 tiene una fuerte dependencia de la ventana 1.

Terminé siendo el que comenzó a trabajar en un marco que podría usarse para que la inicialización de la cuadrícula se definiera una vez, la inicialización del formulario se definiera una vez, las llamadas de datos se definieran una vez … Obtiene la imagen, reduciendo el código duplicado. Mi primer intento de esto tuvo un objeto Grid que tenía llamadas codificadas a un objeto Window para que se abriera al hacer clic en Agregar o Editar. Esto también es un acoplamiento, ya que conecta dos piezas de código que de otro modo no estarían relacionadas en función de un supuesto que podría cambiar.

// Mezcla de JS y pseudocódigo
Grid.init = function () {
// El código inicializa la cuadrícula
$ (“# thisAddBtn”). on (“click”, function () {
Window.open ()
}
}

Lo hace, de hecho, en un proyecto, donde hay una ventana con una cuadrícula y su forma de lado a lado. Si se mantuviera el comportamiento acoplado, esto no hubiera sido posible. En cambio, tratar de editar la cuadrícula debería hacer que aparezca otra ventana con un formulario dentro …

La mejor solución que he encontrado hasta ahora es usar una pequeña cantidad de eventos: un Grid dispara un evento “editGridItem” que recibe un detector personalizado para abrir una ventana o cualquier otro comportamiento que pueda usarse para editar un grid en otros proyectos. Los formularios tienen botones Guardar / Cancelar y cada botón activa un evento “formSave” o “formCancel” respectivamente, donde los oyentes pueden adjuntarse a, digamos, cerrar la ventana que contiene el formulario, actualizar la cuadrícula con los nuevos datos o eliminar el “are” ¿Estás seguro de que quieres salir de la página? ” cosa.

// Nueva inicialización de cuadrícula
// Ubicado en un marco personalizado
Grid.init = function () {
// El código inicializa la cuadrícula
$ (addBtnId) .on (“click”, function () {
$ (gridId) .trigger (“addGridItem”);
});
}

// En otra parte del código específico del proyecto
$ (“# thisGrid”). on (“addGridItem”, function () {
$ (“# thisForm”). trigger (“formAdd”);
});
$ (“# thisForm”). on (“formSave”, function () {
$ (“# thisGrid”). refresh ();
});

El uso de eventos hace que sea mucho más difícil seguir el código, especialmente si estos eventos se usan mucho, pero genera código desacoplado. Una cuadrícula solo se preocupa por lo que hace la cuadrícula, dejando una ventana para encargarse de su propia apertura y cierre y una forma de guardarla o cancelarla. Todo lo demás simplemente se conecta para ese proyecto en particular.