0:22 0 0
Patrón Mediator o mediador

Patrón Mediator o mediador

  DrUalcman |  febrero 112023

En programación, el término "Patrón Mediator" se refiere a un patrón de diseño que se utiliza para reducir la complejidad y mejorar la modularidad de un sistema de software. Este patrón de diseño se utiliza comúnmente en sistemas donde hay múltiples componentes o clases que necesitan comunicarse entre sí, pero no se pueden comunicar directamente.

El Patrón Mediator consiste en un objeto que actúa como intermediario entre otros objetos en un sistema. Este objeto maneja y coordina las comunicaciones entre los objetos sin que estos tengan que conocerse directamente entre sí. En lugar de que los objetos se comuniquen directamente, lo hacen a través del objeto mediador, lo que reduce la complejidad del sistema.

El Patrón Mediator es útil para reducir la dependencia entre los objetos de un sistema, lo que a su vez mejora la modularidad y la capacidad de reutilización del código. También ayuda a centralizar la lógica de comunicación entre los objetos, lo que hace que sea más fácil de entender y mantener.

En resumen, el Patrón Mediator es un patrón de diseño de software que se utiliza para mejorar la modularidad y reducir la complejidad de sistemas de software que involucran múltiples componentes o clases que necesitan comunicarse entre sí.

Un ejemplo en c#

Supongamos que tenemos un sistema que consta de varias clases que necesitan comunicarse entre sí, pero no queremos que estas clases se comuniquen directamente. En su lugar, podemos crear una clase Mediator que maneje la comunicación entre estas clases.

Primero, definimos una interfaz IMediator que representará al Mediator:

public interface IMediator
{
    void SendMessage(string message, Colleague colleague);
}

Luego, definimos una clase ConcretaMediator que implementará la interfaz IMediator:

public class ConcretaMediator : IMediator
{
    private Colleague1 colleague1;
    private Colleague2 colleague2;
    public void SetColleague1(Colleague1 colleague1)
    {
        this.colleague1 = colleague1;
    }
    public void SetColleague2(Colleague2 colleague2)
    {
        this.colleague2 = colleague2;
    }
    public void SendMessage(string message, Colleague colleague)
    {
        if (colleague == colleague1)
        {
            colleague2.Notify(message);
        }
        else
        {
            colleague1.Notify(message);
        }
    }
}

En este ejemplo, ConcretaMediator tiene dos referencias a objetos Colleague1 y Colleague2, y cuando un Colleague envía un mensaje al Mediator a través del método SendMessage, el Mediator reenvía el mensaje al otro Colleague a través del método Notify.

Finalmente, definimos las clases Colleague1 y Colleague2 que interactuarán entre sí a través del Mediator:

public abstract class Colleague
{
    protected IMediator mediator;
    public Colleague(IMediator mediator)
    {
        this.mediator = mediator;
    }
    public abstract void Send(string message);
    public abstract void Notify(string message);
}
public class Colleague1 : Colleague
{
    public Colleague1(IMediator mediator) : base(mediator)
    {
    }
    public override void Send(string message)
    {
        mediator.SendMessage(message, this);
    }
    public override void Notify(string message)
    {
        Console.WriteLine("Colleague1 received message: " + message);
    }
}
public class Colleague2 : Colleague
{
    public Colleague2(IMediator mediator) : base(mediator)
    {
    }
    public override void Send(string message)
    {
        mediator.SendMessage(message, this);
    }
    public override void Notify(string message)
    {
        Console.WriteLine("Colleague2 received message: " + message);
    }
}

En este ejemplo, cada Colleague tiene una referencia al Mediator y utiliza el método Send para enviar un mensaje al Mediator. Cuando el Mediator recibe el mensaje, lo reenvía al otro Colleague a través del método Notify.

Podemos usar estos objetos de la siguiente manera:

var mediator = new ConcretaMediator();
var colleague1 = new Colleague1(mediator);
var colleague2 = new Colleague2(mediator);
mediator.SetColleague1(colleague1);
mediator.SetColleague2(colleague2);
colleague1.Send("Hola, ¿cómo estás?");
colleague2.Send("Estoy bien, gracias.");

En este ejemplo, el Colleague1 envía un mensaje al Mediator, que lo reenvía al Colleague2. Luego, el Colleague2 responde con un mensaje, que también se envía al Mediator y se reenvía al Colleague1.

Espero que esto te ayude a entender cómo implementar este patrón.

Cuándo no utilizarlo

Aunque el patrón Mediator es una herramienta muy útil para reducir la complejidad y mejorar la modularidad de un sistema de software, no es adecuado para todos los casos. Aquí hay algunos casos en los que no se recomienda el uso del patrón Mediator:

* Sistemas simples: El patrón Mediator es útil en sistemas que tienen múltiples componentes o clases que necesitan comunicarse entre sí. En sistemas simples donde solo hay unas pocas clases, puede ser excesivo usar un Mediator para coordinar la comunicación.

* Acoplamiento excesivo: Si el Mediator se convierte en un objeto central en el sistema, puede aumentar el acoplamiento entre las clases y hacer que sea difícil de entender y mantener. Si los objetos pueden comunicarse directamente de manera eficiente, el patrón Mediator no es necesario.

* Sobrecarga: La implementación del patrón Mediator puede agregar sobrecarga adicional al sistema, lo que puede afectar el rendimiento. Si el sistema tiene requisitos de rendimiento estrictos, el uso del patrón Mediator puede no ser la mejor opción.

* Falta de flexibilidad: El patrón Mediator es útil para coordinar la comunicación entre objetos, pero no es muy flexible en términos de agregar nuevos objetos o cambiar la forma en que se comunican. Si el sistema necesita ser altamente adaptable, el patrón Mediator puede limitar esa adaptabilidad.

En resumen, aunque el patrón Mediator es una herramienta valiosa para reducir la complejidad y mejorar la modularidad de un sistema de software, no es adecuado para todos los casos. Se debe tener cuidado al utilizar este patrón y considerar si es apropiado para las necesidades del sistema en cuestión.


0 Comentarios

 
 
 

Archivo