Mediator (Mediador)

Trabajo realizado por:

Guillermo Palacios PelayoFrancisco Mª Saldaña Fresnillo

Juan Sánchez Amador

Índice

1. Definición

2. Motivación

3. Aplicabilidad

4. Estructura

5. Participantes

6. Colaboraciones

7. Consecuencias

8. Implementación

9. Código

10. Usos conocidos

11. Patrones Relacionados

Introducción

Definición: Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.

Clasificación: Patrón de comportamiento

Motivación

Cuando muchos objetos interactúan con otros objetos, se puede formar una estructura muy compleja, con objetos con muchas conexiones con otros objetos. En un caso extremo cada objeto puede conocer a todos los demás objetos.

Objeto1

Objeto5

Objeto4 Objeto3

Objeto2

CASO EXTREMO

Motivación

Para evitar esto el patrón Mediator encapsula el comportamiento de todo un conjunto de objetos en un solo objeto.

Los objetos envían y reciben peticiones a través del mediador, este patrón implementa el comportamiento cooperativo encaminando esas peticiones a los objetos apropiados.

Objeto3

- mediador

Objeto2

- mediador

Objeto1

- mediador

Objeto5

- medidor

Mediador

Objeto4

- mediadorESTRUCTURA MAS CLARA

Aplicabilidad

Utilizaremos el patrón:

Un conjunto grande de objetos se comunica de una forma bien definida, pero compleja.

Dificultad para reutilizar objetos ya que nos referimos a varios objetos para comunicarnos

El comportamiento de muchos objetos que esta distribuido entre varias clases, puede resumirse en una o varias por subclasificación.

Estructura

Participantes

Mediador: define una interfaz para comunicarse con los otros objetos.

Mediador concreto: Implementa el comportamiento cooperativo entre los Objetos. Conoce a los Objetos.

Objetos: Cada objeto conoce su mediador, y usa a este para comunicarse con otros objetos.

Colaboraciones

Los objetos envían y reciben requerimientos (requests) de un objeto mediador. El mediador implementa como se comunican los objetos.

Consecuencias

Ventajas e inconvenientes del patrón Mediator: Reduce herencia :con una subclase llamada Mediador cambiamos el

comportamiento, que de otra manera estaría distribuido en varios objetos.

Desacopla a los objetos: el patrón Mediator promueve bajar el acoplamiento entre objetos. Se puede variar y rehusar objetos y mediadores independientemente.

Simplifica la comunicación entre objetos: Los objetos que se comunican de la forma "muchos a muchos" puede ser remplazada por una forma "uno a muchos" que es menos compleja y más elegante. Además esta forma de comunicación es más fácil de entender.

Abstrae como los objetos cooperan: Haciendo a la mediación un concepto independiente y encapsulándolo en un objeto permite enfocar como los objetos interactúan. Esto ayuda a clarificar como los objetos se relacionan en un sistema.

Centraliza el control: El mediador es el que se encarga de comunicar a los objetos, este puede ser muy complejo, difícil de entender y modificar

Implementación

Importante seguir los siguientes detalles para la implementación de este patrón:

1. Omitir la clase abstracta Mediator. No es necesario crear una clase abstracta Mediador cuando los objetos solo trabajan con un mediador. El acoplamiento abstracto de dicha clase permite que los objetos trabajen con diferentes subclases Mediator y viceversa.

2. Comunicación Objeto y Mediador. Los objetos se comunican su mediador cuanto tiene lugar un evento. Las clases de objetos cada vez que cambian su estado envían notificaciones al mediador. El mediador responde propagando los efectos de dichos eventos a los otros objetos.

Otra forma define al Mediador una interfaz de notificación especializada que permite a los objetos ser mas directos en su comunicación. (AÑADIR ALGO MAS DE smalltalk<7)

Código

Código

using System;using System.Collections;

namespace DoFactory.GangOfFour.Mediator.Structural{

  // Mainapp test application

  class MainApp  {    static void Main()    {      ConcreteMediator m = new ConcreteMediator();

      ConcreteColleague1 c1 = new ConcreteColleague1(m);      ConcreteColleague2 c2 = new ConcreteColleague2(m);

      m.Colleague1 = c1;      m.Colleague2 = c2;

      c1.Send("How are you?");      c2.Send("Fine, thanks");

      // Wait for user       Console.Read();    }  }  

Código

abstract class Mediator  {    public abstract void Send(string message,       Colleague colleague);  }

  // "ConcreteMediator"

 class ConcreteMediator : Mediator  {    private ConcreteColleague1 colleague1;    private ConcreteColleague2 colleague2;

    public ConcreteColleague1 Colleague1    {      set{ colleague1 = value; }    }

    public ConcreteColleague2 Colleague2    {      set{ colleague2 = value; }    }

    public override void Send(string message,       Colleague colleague)    {      if (colleague == colleague1)      {        colleague2.Notify(message);      }      else      {        colleague1.Notify(message);      }    }  }

Códigoabstract class Colleague

  {    protected Mediator mediator;

    // Constructor     public Colleague(Mediator mediator)    {      this.mediator = mediator;    }  }

  // "ConcreteColleague1" class ConcreteColleague1 : Colleague

  {    // Constructor     public ConcreteColleague1(Mediator mediator)       : base(mediator)     {     }

    public void Send(string message)    {      mediator.Send(message, this);    }

    public void Notify(string message)    {      Console.WriteLine("Colleague1 gets message: "         + message);    }  }

Código// "ConcreteColleague2"

  class ConcreteColleague2 : Colleague  {    // Constructor     public ConcreteColleague2(Mediator mediator)       : base(mediator)     {     }

    public void Send(string message)    {      mediator.Send(message, this);    }

    public void Notify(string message)    {      Console.WriteLine("Colleague2 gets message: "         + message);    }  }}

Output Colleague2 gets message: How are you? Colleague1 gets message: Fine, thanks

Usos conocidos La arquitectura de Smalltalk/V para Windows usan objetos parecidos a

mediadores entre los útiles de los dialogos. Una aplicación consiste en un objeto Windows que contiene un objeto de paneles. La biblioteca contiene varios objetos Pane predefinidos; ejemplos de éstos son TextPane, ListBotton… Estos paneles se puede utilizar sin necesidad de heredar de ellos. Un desarrollador de aplicaciones solo hereda de WievManager, una clase que es capaz de organizar la coordinación entre paneles, como el mediador. Cada panel solo conoce a su gestor de vistas, considerándolo como el propietario del panel. Los paneles no se comunican directamente uno con otros.Smalltalk/V usa un mecanismo de eventos para la comunicación Pane-ViewManager. Un panel genera un evento cuando quiere obtener información del mediador o si quiere informar a este de que a ocurrido algo significativo. Un evento define un símbolo que lo identifica. El gestor de vistas registra un selector del método con el panel para manejar el evento.

Otra aplicación es coordinar actualizaciones complejas. Un ejemplo de esto es el GestorDeCambios que se menciona en le patrón Observer.

También aperece otra aplicación en el framework de dibujo Unidraw.

Patrones relacionados

Un patrón muy parecido a éste es el Facade que se diferéncia en que abstrae un sistema de objetos proporcionado una interfaz mas conveniente, utilizando un protocolo unidireccional (Fachada realiza solo peticiones a las clases del subsistema pero no a la inversa), mientras que el Mediator usa un protocolo mutidireccional.

Con el patrón Observer los objetos pueden comunicarse con el mediador.

Bibliografía

Patrones de diseño – Elementos de software orientado objetos reutilizables Enciclopedia libre - Wikipedia http://www.dofactory.com/Patterns/PatternMediator.aspx#_self2