Patrón Mediator en Kotlin

En la programación orientada a objetos, siempre debemos intentar diseñar el sistema de tal manera que los componentes estén acoplados libremente y sean reutilizables. Este enfoque hace que nuestro código sea más fácil de mantener y probar.

En la vida real, sin embargo, a menudo necesitamos lidiar con un conjunto complejo de objetos dependientes. Aquí es cuando el Patrón de mediador puede resultar útil.

Este patrón proporciona una clase mediadora que normalmente maneja todas las comunicaciones entre diferentes clases y admite un fácil mantenimiento del código mediante un acoplamiento flexible. El patrón de mediador se incluye en la categoría de patrón de comportamiento.

En caso de que tengamos muchos objetos que interactúan entre sí, terminamos con un código muy complejo y no mantenible. Por eso es un buen caso utilizar el patrón de diseño Mediator. Normalmente creamos una cantidad suficiente de objetos que permitan comunicarse entre sí con la intención de construir entidades que actúen juntas por un motivo específico. Cuando algo le sucede a un objeto, otro tiene que hacer algo o cambiar su comportamiento.

Al construir un código complejo que permita que muchos objetos (2 o más) se comuniquen entre sí, terminará con un código espagueti, no mantenible, y enfrentará una pesadilla cada vez que quiera encontrar y corregir un error o mejorar el código. Este problema aumenta si normalmente tiene una interacción compleja y de ida y vuelta.

La solución viene usando el patrón Mediator. Este patrón le permite mantener toda la lógica de la comunicación en un solo lugar (objeto) y cada objeto utilizado para interactuar con otros objetos, ahora interactúa solo con el que es consciente de cómo actuar en cada ocasión.

Entonces, podemos entender muy rápidamente que los objetos están desacoplados. El código es más simple de lo que solía ser. Eso es exactamente lo que intentamos lograr utilizando Programación Orientada a Objetos y patrones de diseño.

Estructura del patrón Mediator

En el diagrama UML anterior, podemos identificar a los siguientes participantes:

Mediator: Define la interfaz que utilizan los objetos Colleague para comunicarse

Colleague: Define la clase abstracta que tiene una única referencia al Mediador

ConcreteMediator: Encapsula la lógica de interacción entre los objetos Colleague

ConcreteColleague1 y ConcreteColleague2: Se comunican solo a través del Mediator

Como podemos ver, los objetos Colega no se refieren directamente entre sí. En cambio, toda la comunicación la realiza el Mediador.

En consecuencia, ConcreteColleague1 y ConcreteColleague2 se pueden reutilizar más fácilmente.

Además, en caso de que necesitemos cambiar la forma en que los objetos Colega trabajan juntos, solo tenemos que modificar la lógica de ConcreteMediator o podemos crear una nueva implementación del Mediator.