Optimización del Diseño de Software: Acoplamiento, Cohesión y Patrón Controlador

Patrón Bajo Acoplamiento

Problema

¿Cómo mantener un bajo acoplamiento para lograr, entre otras cosas, alta reutilización?

Nota

El acoplamiento mide el grado en que una clase está conectada a otra, tiene conocimiento de otra o, de alguna manera, depende de otra.

Situaciones de Acoplamiento

• Una clase X tiene un miembro o declara una variable de clase Y.
• Una clase X tiene un método que toma como parámetro un objeto de clase Y.
• Una clase X es un descendiente (subclase) de Y.

Desventajas del Alto Acoplamiento

• Los cambios en unas clases implican cambios en las clases relacionadas.
• Dificultad de comprensión del sistema.
• Dificultad de reutilización de las clases.
• ¿Posible pérdida de rendimiento? (Aunque no siempre es el factor principal).

Solución

Asignar la responsabilidad de manera que el acoplamiento permanezca bajo.

Consideraciones

• El bajo acoplamiento permite crear clases más independientes y más reutilizables, lo que implica mayor productividad.
• El acoplamiento puede no ser un objetivo primordial si la reutilización no es una meta clave del proyecto.
• La especialización (herencia) es una forma fuerte de acoplar clases.
• Un acoplamiento excesivamente bajo puede producir diseños pobres, con objetos sobrecargados o complejos (patrón God Object).

Patrón Alta Cohesión

Problema

¿Cómo mantener la complejidad de una clase en niveles manejables?

Nota

La cohesión mide el grado en que están relacionadas las responsabilidades de una clase. Una alta cohesión significa que las responsabilidades de un elemento están fuertemente relacionadas y enfocadas.

Desventajas de la Baja Cohesión

• Clases difíciles de comprender.
• Clases difíciles de reutilizar.
• Clases difíciles de mantener.
• Clases delicadas, muy afectadas por los cambios (frágiles).

Solución

Asignar responsabilidades de manera que la cohesión se mantenga alta.

Patrón Controlador

Problema

¿Quién debería ser responsable de manejar un evento del sistema?

Nota

Un evento del sistema es un suceso significativo en el dominio del problema, usualmente generado por un actor externo (ej: usuario interactuando con la interfaz).

Solución

Asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que represente una de las siguientes opciones:

• Controlador de Fachada (Facade Controller): Representa al sistema completo, un dispositivo raíz o una organización (ej: SistemaPedidos, TerminalVenta). Adecuado cuando hay pocos eventos o no se desea granularidad.
• Controlador de Rol (Role Controller): Representa una parte activa o rol en el mundo real que está involucrado en la tarea (ej: GestorDePagos, AdministradorDeUsuarios).
• Controlador de Caso de Uso (Use Case Controller): Representa un manejador artificial para un escenario o caso de uso específico (ej: ProcesarVentaController, IniciarSesionController). Es la opción más común.

Sugerencias

• Se puede utilizar un controlador por cada Caso de Uso (CdU), de manera que se encargue de controlar el estado del CdU, la secuencia de eventos, etc. Esto promueve la alta cohesión del controlador.
• Una vez que el controlador recibe un evento, debe delegar el trabajo a otros objetos del dominio para no verse sobrecargado. Un controlador que hace demasiado trabajo tiene baja cohesión y alto acoplamiento.