La logística de PideYa es una conversación a tres bandas que no para: la cocina termina un pedido y busca repartidor; el repartidor acaba una entrega y pregunta si hay algo pendiente; un pedido lleva demasiado tiempo esperando y hay que reasignarlo. En el código actual, cocina, pedidos y repartidores se conocen y se llaman entre sí: una malla donde cada clase guarda referencias a las demás, y donde añadir una pieza (¡llegan los repartidores en moto con nevera!) obliga a tocarlo todo. Mediator propone rehacer la topología: que ningún colega hable con otro directamente y toda la coordinación pase por un objeto central — convertir la malla en una estrella. Y con la misma honestidad de siempre: veremos también cómo esa estrella puede degenerar en el temido mediador-dios.

1. El problema en PideYa: la malla del reparto
2. Malla vs. estrella: la cuenta del acoplamiento
3. Intención y estructura del patrón
4. Implementación Java completa: CentralReparto
5. La conversación en el tiempo
6. Variantes del patrón
7. El riesgo del mediador-dios
8. Cuándo usarlo y cuándo no
9. Relación con otros patrones
10. Errores comunes
11. Ejercicios y conclusión

El estado actual, resumido en tres clases que se abrazan:

Los síntomas, uno a uno:

• Todos conocen a todos: Cocina guarda repartidores, Repartidor guarda la cocina, y el monitor de pedidos atascados conocerá a ambos. Cada referencia cruzada es una dependencia de compilación y un new/setter que alguien mantiene.
• La lógica de coordinación está repartida: parte de "cómo se asigna un repartidor" vive en Cocina, parte en Repartidor. Para entender el protocolo completo hay que leer todas las clases; para cambiarlo, tocarlas todas.
• Reutilización imposible: un Repartidor no puede probarse ni reutilizarse sin una Cocina de verdad colgando de él.
• Crecer duele cuadráticamente: añadir el monitor de atascos, o repartidores externos de una subcontrata, significa nuevas referencias cruzadas en las clases existentes.

Y nótese lo que no es el problema: cada clase hace bien su trabajo individual (cocinar, repartir). Lo que sobra es que además carguen con el protocolo de coordinación. Ese protocolo pide un dueño único.

Con n participantes que colaboran todos con todos, la malla tiene hasta n(n−1)/2 conexiones; la estrella, exactamente n. Con 4 colegas: 6 frente a 4; con 8: 28 frente a 8. Pero más importante que la cuenta es quién sabe qué: en la estrella, cada colega solo conoce al mediador — añadir el quinto colega no toca a los otros cuatro.

Intención (GoF): definir un objeto que encapsula cómo interactúa un conjunto de objetos. Mediator promueve el bajo acoplamiento evitando que los objetos se refieran unos a otros explícitamente, y permite variar su interacción de forma independiente.

La regla de oro que define al patrón: los colegas nunca se referencian entre sí. Un colega hace su trabajo local y, cuando pasa algo relevante para otros, se lo cuenta al mediador; el mediador decide a quién toca reaccionar y se lo ordena.

La interfaz del mediador. Sus métodos son los acontecimientos que los colegas comunican — nómbralos por lo que pasó, no por lo que hay que hacer (eso lo decide el mediador):

Los colegas, ahora ligeros: hacen lo suyo y avisan. Repartidor ya no conoce a Cocina; Cocina ya no recorre repartidores:

El mediador concreto: aquí, y solo aquí, vive el protocolo completo de coordinación — legible de arriba abajo en una clase:

Repara en lo ganado:

• El protocolo es un solo texto: "si hay repartidor en zona, asignar; si no, encolar; cuando alguien se libere, mirar la cola". Antes estaba esparcido en tres clases.
• Cambiar el criterio de asignación ("el más cercano" en vez de "el primero disponible") toca una línea de una clase. De hecho, ese criterio es una familia de algoritmos intercambiables... exactamente lo que Strategy reificará en su lección — el mediador será su cliente perfecto.
• Testear Repartidor ahora es trivial: se le inyecta un MediadorReparto falso y punto.
• Añadir un colega nuevo (el MonitorAtascos que detecta esperas largas y llama a pedidoAtascado) no toca ni a Cocina ni a Repartidor.

El mismo escenario del principio — un repartidor se libera y hay un pedido esperando — ahora en estrella:

• Con o sin interfaz Mediator: si solo existirá una central, GoF admite saltarse la interfaz y usar la clase concreta. Nosotros la mantenemos por testabilidad (mediadores falsos en los tests de los colegas) y porque una CentralRepartoExterna (subcontrata) es plausible.
• ¿Cómo avisa el colega al mediador? Nuestra versión usa métodos específicos (pedidoListo(...)), clara y tipada. La alternativa es un método único genérico (notificar(colega, "PEDIDO_LISTO", datos)) — más flexible, menos segura; en cuanto lo veas, estás a un paso del bus de eventos (mención en la puerta de Observer y desarrollo en el módulo 6).
• Mediador de UI: el ejemplo canónico del GoF es un diálogo cuyos widgets (botón, lista, campo de texto) se coordinan a través del diálogo — "al marcar la casilla se habilita el botón". Si has escrito un controlador de pantalla que coordina sus componentes, has escrito un mediador.

La crítica clásica al patrón, y es justa: el mediador concentra el acoplamiento en lugar de eliminarlo. Eso es bueno (está localizado, legible, cambiable) hasta que deja de serlo: la central que además calcula rutas, aplica bonificaciones, decide turnos y envía notificaciones se convierte en un objeto-dios — la mayor mancha de responsabilidad del sistema, intocable por miedo y cuello de botella de todos los cambios. Señales de alarma y antídotos:

• El mediador hace trabajo de dominio en vez de coordinar → extrae ese trabajo a los colegas o a servicios (SRP: el mediador coordina, los colegas trabajan).
• El mediador crece con métodos que solo interesan a una pareja de colegas → quizá esa pareja merece hablarse directamente o tener su propio mediador pequeño.
• Los algoritmos dentro del mediador varían → extráelos como estrategias (Strategy) y deja al mediador la orquestación.

La versión honesta del contrato: Mediator no reduce la complejidad del protocolo — la muda a un único lugar. Si el protocolo es intrínsecamente enorme, el mediador será grande; el patrón te debe orden, no milagros.

Úsalo cuando:

• Un conjunto de objetos colabora de formas complejas y cambiantes, y las referencias cruzadas se multiplican.
• Quieres reutilizar o testear los colegas sueltos, sin arrastrar a sus interlocutores.
• El protocolo de coordinación merece ser una pieza con nombre propio, legible y modificable de una vez.

Evítalo cuando:

• Solo hay dos colaboradores con una relación simple: una llamada directa (o un Observer) basta; un mediador entre dos es burocracia.
• El "protocolo" es trivial y estable: la malla de dos hilos no duele.
• Estarías creando el mediador-dios desde el día uno: si la clase nace con veinte responsabilidades, el problema es de reparto de dominio, no de topología.

• Observer: la otra forma de desacoplar comunicación — y la confusión más frecuente del módulo. Adelanto de una línea (careo completo en la comparativa): Observer difunde "ha pasado X" a quien quiera oírlo, sin protocolo central; Mediator dirige un protocolo con papeles conocidos. Además, un mediador puede implementarse escuchando a sus colegas como observador.
• Facade: parecido superficial (un objeto delante de varios). La fachada ofrece una interfaz unidireccional simplificada hacia un subsistema que no la conoce; el mediador mantiene un diálogo bidireccional con colegas que sí lo conocen.
• Strategy: los criterios variables del mediador (asignación de repartidor) se extraen como estrategias.
• Singleton: la tentación de hacer CentralReparto singleton global; mejor inyectarla, por los motivos que ya sufrimos en el módulo 2.

• Colegas que se guardan referencias entre sí "solo para este caso": la primera referencia cruzada reabre la malla; a la tercera, tienes malla y mediador (lo peor de ambos mundos).
• El mediador que trabaja: si CentralReparto calcula la ruta o cobra la entrega, ha dejado de coordinar. Coordinar es decidir quién y cuándo; el cómo es de los colegas.
• Ciclos de notificación: el mediador ordena a un colega, el colega notifica al mediador, que vuelve a ordenar... Protégete distinguiendo "aviso de acontecimiento" (colega → mediador) de "orden" (mediador → colega) y no notifiques acontecimientos desde las órdenes recibidas.
• Interfaz de mediador que calca una implementación: métodos como asignarAlPrimerDisponible(...) fijan el protocolo en la interfaz; nómbralos por acontecimientos (pedidoListo) para poder cambiar la política sin tocar a los colegas.
• Convertirlo en cajón de sastre: "ya que todo pasa por aquí, meto también el logging, la caché y las métricas". Cada inquilino nuevo acerca el mediador-dios.

Implementa MonitorAtascos: cada minuto revisa los pedidos en espera y, si alguno lleva más de 10 minutos, llama a central.pedidoAtascado(pedido). Además, la central debe entonces notificar a soporte con el Notificador del módulo 2. Indica qué clases se crean, cuáles se modifican y cuáles quedan intactas.

Dibuja (o describe) las dependencias de estas cuatro clases antes y después de aplicar Mediator: Cocina, Repartidor, PantallaSeguimiento (muestra al cliente dónde está su pedido) y CentralReparto. ¿Cuántas referencias entre clases hay en cada versión?

Un año después, CentralReparto tiene 1.800 líneas: asigna repartidores, calcula rutas con tráfico, aplica el bono por lluvia, gestiona los turnos y envía las notificaciones push. Propón un reparto: ¿qué se queda en el mediador y a dónde va cada cosa? (Nombra patrones ya vistos donde apliquen.)

Solución 1: se crea MonitorAtascos (colega nuevo que solo conoce MediadorReparto); se modifica solo CentralReparto (el cuerpo de pedidoAtascado añade notificadorSoporte.enviar(...), con el notificador inyectado en su constructor); quedan intactas Cocina, Repartidor y la interfaz MediadorReparto (el método ya existía). Ese es el dividendo de la estrella: crecer sin tocar a los vecinos.

Solución 2: antes (malla): Cocina→Repartidor, Repartidor→Cocina, PantallaSeguimiento→Cocina, PantallaSeguimiento→Repartidor — 4 referencias (y creciendo cuadráticamente con cada colega). Después (estrella): Cocina→Mediador, Repartidor→Mediador, PantallaSeguimiento→Mediador, y el mediador conoce a sus colegas — la coordinación completa queda en 1 clase y cada colega tiene exactamente 1 dependencia, testeable con un mediador falso.

Solución 3: se queda en CentralReparto únicamente la orquestación: recibir acontecimientos, consultar piezas y ordenar asignaciones. Se van: el cálculo de rutas a un ServicioRutas (colega/servicio de dominio); el criterio de asignación y el bono por lluvia a estrategias (Strategy) intercambiables que la central usa; la gestión de turnos a un GestorTurnos propio (la central le pregunta disponibilidad); las notificaciones push a los Notificador existentes, invocados por la central pero implementados fuera — o mejor aún, disparadas por los cambios de estado del pedido vía Observer, que es justo la lección que sigue tras la próxima.

Mediator reordena la topología de la colaboración: de la malla donde cocina, pedidos y repartidores se conocían todos con todos, a la estrella donde cada colega solo conoce a CentralReparto y el protocolo de coordinación vive entero, legible y cambiable, en un único lugar. Has visto la cuenta del acoplamiento (n frente a n²), la conversación en secuencia, sus variantes, y la advertencia que lo acompaña siempre: el mediador concentra el acoplamiento — vigila que no engorde hasta mediador-dios, extrayendo trabajo a colegas y algoritmos a estrategias.

El siguiente patrón cambia de escenario pero no de familia: del reparto al carrito del cliente. Editar el carrito es ir probando —añado esto, quito aquello, aplico un cupón— y el cliente quiere poder volver atrás sin que el carrito exponga sus tripas para que alguien las fotografíe. Guardar y restaurar estado sin romper la encapsulación: ese equilibrio delicado es exactamente la especialidad de Memento.