Desacoplamiento de módulos de API – CodesCode

El costo de cambiar o mantener el software es principalmente alto debido a la cascada, que es un cambio significativo en un sistema de software acoplado.

El costo del software consiste principalmente en el costo de mantener el software. El costo de cambiar o mantener el software es principalmente alto debido a la cascada, que es un cambio significativo en un sistema de software acoplado. Por lo tanto, desacoplar un sistema de software casi siempre resulta en un sistema mejor diseñado con un costo bajo de cambio. Veamos esto con la ayuda de un ejemplo.

Tomando un ejemplo

Supongamos que eres una clínica veterinaria y necesitas un sistema de software para gestionar las visitas a la clínica: registrar visitas, asignar procedimientos de visita y crear facturas de visita.

Probablemente tendrías tres servicios, uno para cada una de las funcionalidades mencionadas anteriormente:

Ahora, para agregar las interacciones entre los módulos:

El servicio de visita recibe como entrada al cliente, la mascota, la fecha y hora de la visita y crea una visita.
El servicio de procedimientos recibe una visita y agrega uno o más procedimientos a la visita.
El servicio de facturas recibe una visita y crea una factura para los procedimientos de la visita.

Supongamos que la entidad de visita se ve así:

visita {  identificadorVisita  nombreCliente  nombreMascota  fechaVisita  procedimientos [] }

La entidad de procedimiento probablemente se vería así:

procedimiento {  identificadorProcedimiento  tipoProcedimiento  precio }

Para crear una factura, el servicio de facturas necesitaría tanto los detalles de la visita como el procedimiento realizado:

factura {  detallesVisita  procedimientosRealizados []  montoDebido }

Hay un par de opciones sobre qué tipo de datos podríamos estar pasando al servicio de facturas:

Podría recibir el objeto de visita y el array de objetos de procedimientos. Luego, crearía los detalles imprimibles a partir del objeto de visita y el array de procedimientos y calcularía la suma de los precios de cada procedimiento en el array de procedimientos.

Podría recibir el identificadorVisita y llamar al servicio de visita para obtener los detalles de la visita impresos y al servicio de facturas para obtener la lista de nombres de los procedimientos y los precios de la lista de procedimientos realizados durante la visita.

Accediendo al acoplamiento

¿Cuál de las dos opciones anteriores es la mejor opción de diseño? Veamos qué tan desacoplado o acoplado está este sistema de software simple en ambas opciones.

Opción 1: Cuando se pasan objetos completos

Aquí, cualquier cambio en el esquema de visita, por ejemplo, cuando agregamos un número de teléfono del cliente, significa que necesitamos cambiar el servicio de visita, pero también el servicio de facturas. El servicio de facturas recibe un objeto de visita y crea los detalles imprimibles de la visita para ponerlos en la factura.

También, cualquier cambio en el procedimiento, como agregar un nuevo tipo de procedimiento, no solo requeriría un cambio en el servicio de procedimientos, sino también en el servicio de facturas, ya que el servicio de facturas recibe un objeto de procedimiento. Necesitaría crear la versión imprimible del nuevo tipo de procedimiento.

Opción 2: Cuando solo se envían datos que no cambian

En este caso, el servicio de facturas solo recibe identificadorVisita y llama al servicio de visita, ya que debe imprimir en la factura los detalles de la visita. De esta manera, el esquema de visita puede cambiar según sea necesario y solo requeriría un cambio en el servicio de visita. El contrato entre el servicio de facturas y el servicio de visita, como se muestra a continuación, permanecería sin cambios:

ObtenerDetallesVisita(identificadorVisita) → cadena

De manera similar, el servicio de facturas llamaría al servicio de procedimientos para obtener un array de nombres de procedimientos y números de precios para un identificadorVisita, como se muestra a continuación. Luego, si se agregan nuevos procedimientos, solo afectarían al servicio de procedimientos; el servicio de facturas no necesitaría cambiar.

ObtenerProcedimientosVisitaConPrecios(identificadorVisita) → Dict<cadena, decimal>

Conclusión

Cuando diseñamos software, si reducimos el acoplamiento entre módulos, hacemos que el diseño sea más modular y nos aseguramos de que los cambios en un módulo no afecten a otros módulos, o al menos, que el cambio en cascada sea limitado, lo que hace que los cambios sean de bajo costo.

¡Gracias por leer! Por favor, hazme saber tus opiniones.