Acoplamiento en Genexus.

Es bien conocido en ingeniería de software que las aplicaciones deben tener un diseño modular con bajo acoplamiento y alta cohesión, para que sean más fáciles de mantener y de instalar.

Alta cohesión , es sinónimo de que los componentes parecidos o que se referencian mucho entre ellos, deben estar lo más cerca posible.

Bajo acoplamiento, favorece que pueda cambiar un componente, sin afectar a quienes interactúan con él.

Estas características, son deseables a varios niveles. A nivel de aplicaciones, a nivel de directorios virtuales o webapps, a nivel de módulo dentro de la KB, el la base de datos y a nivel de objetos en la KB.

Hoy me interesa hablar sobre cómo estudiar el acoplamiento entre  objetos.

Hay dos tipos de referencias entre  objetos, de entrada (quienes llaman o usan al objeto que estoy mirando) y de salida (los objetos llamados o usados por el objeto que estudio).

Estudiemos algunos casos simplificados.

OBJETO 1) Llamado por muchos y no llama a ningún otro.

En este caso, varios objetos referencian al objeto. Esto puede ser un objeto de uso común del tipo utilitario o biblioteca, como dar un numerador, grabar un log, mandar un mail.

Estos objetos que son muy llamados, deben ser estables, pues si los cambiamos, afectamos a varios otras partes del sistema.

Son buenos candidatos para realizarle pruebas unitarias detalladas.

OBJETO 2) No lo llama nadie y llama a muchos.

Esto puede ser un objeto main, servicios o objetos con UI, que van a necesitar llamar a otros para lograr hacer algo útil. Pueden ser parte de la API de mi aplicación.

Al llamar a varios objetos, se van a ver afectados por los cambios que se produzcan en los objetos llamados. 

Estos objetos van a necesitar pruebas funcionales más intensas.

OBJETO 3) Llamado y llamador.

Estos objetos deberán ser llamados para realizar su tarea, y necesitan llamar a otros.

Harán validaciones y transformaciones.

Estos objetos son delicados, pues se pueden ver afectados por los objetos llamados y pueden afectar a quienes lo llaman.

Son buenos candidatos a tener una tasa de cambio elevada.

OBJETO 4) No interactúa con nada.

Es un desarrollo monolítico, en un solo objeto hago todo. No es muy útil, solo aparece en casos triviales. Poco lo afectan.

Para que me puede servir esta clasificación?

En el caso que tenga que mantener una KB por un tiempo prolongado, me va interesar poder realizar esa tarea de la forma más productiva posible.

Una regla bastante útil para identificar objetos complicados (o que van a complicar en el futuro) de mantenerse es ver aquellos objetos que llaman a muchos objetos. Seria ver todos los objetos de tipo 2 y 3, y quedarse con los que tienen mayor cantidad de dependencias de salida.

Estos objetos posiblemente estén haciendo más de una cosa y con seguridad se pueden simplificar para mejorar su programación.

Esto nos va a llevar a código más pequeño, con un único objetivo y más fácil de entender. Con eso, el mantenimiento de la aplicación se hace más productivo.

Resumen.

Para mejorar mi KB, identifico objetos que hagan muchas referencias y hago refactoring del mismo, generalmente extrayendo código a procedimientos que pueda reutilizar en otro objeto. También puedo dividir el objeto, si veo que hace más de una cosa.

Aplicando esta sencilla regla en forma habitual, se facilita mucho el mantenimiento.