Patrón Mediator explicado con ejemplos

Intención y el problema que resuelve

Intención: definir un objeto que encapsule cómo interactúan un conjunto de objetos. Mediator promueve el acoplamiento débil al evitar que los objetos se refieran explícitamente unos a otros, y permite variar su interacción de forma independiente. Es uno de los patrones de comportamiento del libro de la Banda de los Cuatro (Gang of Four, GoF).

Considera un formulario de registro con una casilla "cuenta de empresa", un campo de nombre de empresa, un campo de correo y un botón de envío. Cuando se marca la casilla, el campo de empresa debe aparecer y volverse obligatorio. El botón de envío solo debe estar habilitado cuando todos los campos obligatorios sean válidos. Si cada componente actualiza directamente a los otros, la casilla conoce el campo de empresa y el botón, el campo de correo conoce el botón, y así sucesivamente. Cada regla nueva añade más referencias cruzadas, y ningún componente se puede reutilizar en otro formulario.

Con un mediador, los componentes solo informan de eventos como "he cambiado". El objeto formulario, que actúa como mediador, contiene todas las reglas sobre cómo se afectan los campos entre sí. Los componentes se vuelven simples y reutilizables, y la lógica de interacción queda en un solo lugar.

Estructura y participantes

Sin un mediador, n componentes que se hablan todos entre sí pueden necesitar hasta n × (n − 1) / 2 enlaces. Con un mediador, cada componente tiene exactamente un enlace: el del mediador.

Implementación en TypeScript

Cada campo informa de sus cambios al mediador. SignUpForm es el mediador concreto: muestra u oculta el campo de empresa y habilita el botón.

interface Mediator {
  notify(sender: Component, event: string): void;
}

class Component {
  constructor(protected mediator: Mediator, readonly name: string) {}
}

class Checkbox extends Component {
  checked = false;
  toggle() { this.checked = !this.checked; this.mediator.notify(this, "change"); }
}
class TextField extends Component {
  value = "";
  visible = true;
  type(text: string) { this.value = text; this.mediator.notify(this, "change"); }
}
class Button extends Component { enabled = false; }

class SignUpForm implements Mediator {
  isCompany = new Checkbox(this, "isCompany");
  company = new TextField(this, "company");
  email = new TextField(this, "email");
  submit = new Button(this, "submit");
  constructor() { this.company.visible = false; }

  notify(sender: Component, event: string) {
    if (sender === this.isCompany) this.company.visible = this.isCompany.checked;
    const emailOk = this.email.value.includes("@");
    const companyOk = !this.company.visible || this.company.value.length > 0;
    this.submit.enabled = emailOk && companyOk;
    console.log(sender.name, event, "-> submit enabled:", this.submit.enabled);
  }
}

const form = new SignUpForm();
form.email.type("[email protected]"); // email change -> submit enabled: true
form.isCompany.toggle();            // isCompany change -> submit enabled: false
form.company.type("Acme");          // company change -> submit enabled: true

Fíjate en que Checkbox y TextField no tienen idea de que existan otros campos. Podrías reutilizarlos en un formulario completamente distinto dándoles otro mediador.

Cuándo usarlo y cuándo no

• Úsalo cuando un grupo de objetos se comunica de formas complejas pero bien definidas, y las dependencias entre ellos son difíciles de seguir.
• Úsalo cuando quieras reutilizar componentes que ahora no se pueden separar porque se referencian entre sí.
• Úsalo cuando las reglas de interacción cambian a menudo y quieres editarlas en un solo lugar.
• No lo uses para dos objetos que simplemente se llaman entre sí; una llamada directa es más clara.
• No lo uses cuando los componentes solo necesitan difundir eventos a quien esté interesado. Un emisor de eventos simple (Observer) es más ligero.

Usos en el mundo real

• Controladores de formularios y diálogos en frameworks de interfaz: un componente padre posee el estado y decide cómo se afectan entre sí las entradas hijas, mientras que los hijos solo lanzan eventos. En React, "elevar el estado" a un padre común sigue esta idea.
• Aplicaciones de chat: los usuarios no se envían mensajes directamente entre sí; una sala de chat o un servidor recibe cada mensaje y lo entrega a los miembros adecuados.
• Brokers de mensajes y buses de eventos entre servicios: los emisores publican en el broker, que encamina los mensajes a receptores que los emisores no conocen.
• El control de tráfico aéreo es la analogía clásica: los aviones no negocian con todos los demás aviones, hablan solo con la torre de control.

Mediator frente a Observer y otros patrones