DEV Community

Cover image for Mediator Pattern: comunicazione senza caos
Dev-Iadicola
Dev-Iadicola

Posted on • Originally published at iadicola.it

Mediator Pattern: comunicazione senza caos

Il problema: tutti parlano con tutti

Un form complesso ha 10 campi interdipendenti. Selezionare "tipo: azienda" mostra il campo P.IVA e nasconde il codice fiscale. Selezionare "paese: estero" disabilita il CAP e cambia il formato del telefono. Cambiare la provincia aggiorna la lista dei comuni. Ogni campo conosce gli altri e li manipola direttamente: $tipoField->onChange(function() use ($pivaField, $cfField) { ... }).

Con 10 campi che comunicano tra loro hai potenzialmente 90 connessioni dirette (N*(N-1)). Aggiungere l'undicesimo campo richiede di aggiornare tutti quelli che interagiscono con esso. Rimuoverne uno rompe tutti quelli che lo referenziano. E un groviglio che nessuno vuole toccare.

Il Mediator Pattern introduce un coordinatore centrale: i campi non comunicano tra loro, comunicano con il mediator. Il mediator conosce le regole di interazione e coordina le risposte. Ogni campo conosce solo il mediator, non gli altri campi.

Cos'e il Mediator Pattern: definizione formale

Il Gang of Four definisce il Mediator come un pattern comportamentale che "definisce un oggetto che incapsula come un insieme di oggetti interagisce. Il Mediator promuove l'accoppiamento lasco impedendo agli oggetti di riferirsi esplicitamente l'un l'altro". La struttura prevede:

  • Mediator: l'interfaccia con un metodo notify(sender, event)
  • ConcreteMediator: implementa la logica di coordinamento tra i componenti
  • Colleague: ogni componente che comunica tramite il mediator. Conosce il mediator, non gli altri colleague.

Esempio teorico: una chat room

Una chat room e l'esempio classico del Mediator. Ogni utente (Colleague) invia messaggi alla room (Mediator), non direttamente agli altri utenti. La room decide chi riceve il messaggio: tutti (broadcast), un gruppo (canale), o un singolo utente (messaggio privato).

  • ChatRoom::notify(User $sender, string $message, ?string $channel) riceve il messaggio
  • Se il canale e specificato, inoltra solo ai membri del canale
  • Se e un messaggio privato (@user), inoltra solo al destinatario
  • Altrimenti, broadcast a tutti tranne il mittente

Aggiungere un utente alla room non richiede di modificare gli altri utenti. Aggiungere regole (moderazione, filtro spam, rate limiting) richiede di modificare solo il mediator. I colleague restano semplici.

Esempio teorico: orchestrazione di microservizi

Un ordine e-commerce coinvolge: inventario, pagamento, spedizione, notifiche, fatturazione. Senza mediator, ogni servizio chiama gli altri direttamente — un groviglio di dipendenze. Con un OrderOrchestrator (mediator), il flusso diventa lineare: il payment service notifica l'orchestrator "pagamento riuscito", l'orchestrator chiama l'inventario per riservare, poi la spedizione per preparare, poi la fatturazione per emettere, poi le notifiche per informare il cliente.

Mediator vs Observer

  • Observer: comunicazione one-to-many. Un subject notifica tutti gli observer. Gli observer non si conoscono ma il subject non coordina le loro risposte.
  • Mediator: comunicazione many-to-many coordinata. Il mediator riceve notifiche da qualsiasi colleague e decide come e chi coinvolgere nella risposta.

L'Observer e passivo: "e successo X, fate quello che volete". Il Mediator e attivo: "e successo X, quindi tu fai A, tu fai B, e tu aspetti". Se serve coordinamento tra le risposte, il Mediator e la scelta giusta.

Quando usare il Mediator Pattern

  • Usa il Mediator quando molti oggetti comunicano tra loro in modi complessi e le dipendenze dirette sono un groviglio
  • Usa il Mediator quando vuoi centralizzare le regole di interazione in un unico punto modificabile
  • Usa il Mediator quando aggiungere o rimuovere un componente non deve richiedere modifiche agli altri
  • Non usare il Mediator se i componenti hanno interazioni semplici e dirette: il mediator aggiunge un layer di indirezione non necessario
  • Attenzione: il mediator può diventare un God Object se accumula troppa logica. Se cresce troppo, suddividilo in sotto-mediator specializzati.

Il Mediator Pattern e il pattern del coordinamento centralizzato: trasforma una rete di dipendenze N-a-N in una stella con il mediator al centro. La complessità non scompare — si sposta in un punto unico, visibile e manutenibile.


👉 Leggi l'articolo completo su iadicola.it

Top comments (0)