Chain of responsibility è un design pattern comportamentale. Lo utilizziamo quando vogliamo dare a più di un oggetto la possibilità di gestire richieste.
Problema
Dopo il rilascio di un gioco, sviluppato in Java, contenuto all’interno di distributore di gomme da masticare, la nostra azienda sta ricevendo più email di quante ne riesca a gestire. Dall’analisi dei contenuti, le email possono essere classificate in quattro tipi: congratulazioni dai fan che si amano il nuovo gioco, lamentele dei genitori i cui figli sono diventati fanatici e richieste di installazione della macchina in nuovi posti. Infine, c’è anche una certa quantità di spam.
Tutte le email dei fan devono andare dritte all’amministratore delegato, tutte le lamentele al dipartimento legale e tutte le richieste di nuove macchine all’area commerciale. Lo spam deve essere cancellato.
Dopo aver sviluppato delle logiche di intelligenza artificiale per classificare le email, l’esigenza è di progettare un modo per utilizzarle.
Soluzione
Con il pattern Chain of responsibility, creiamo una catena di oggetti (SpamHandler, FanHandler, ecc.) che esaminano una richiesta. Ogni oggetto, a turno, esamina la richiesta: se può gestirla, lo fa; altrimenti la passa al suo successore.
Quando un’email viene ricevuta, è passata al primo gestore SpamHandler. Se SpamHandler non è in grado di gestire la richiesta, la passa a FanHandler. E così via…
Conseguenze
Vantaggi:
• disaccoppia il mittente della richiesta dai suoi destinatari;
• semplifica il nostro oggetto, poiché quest’ultimo non deve conoscere la struttura della catena né avere riferimenti diretti ai suoi membri;
• ci permette di aggiungere o rimuovere dinamicamente le responsabilità, cambiando i membri o l’ordine della catena.
Usi:
• è utilizzato tipicamente in sistemi a finestre per gestire eventi come i click del mouse o la pressione dei tasti sulla tastiera.
Svantaggi:
• l’esecuzione della richiesta non è garantita: potrebbe fermarsi prima della fine della catena se nessun oggetto la gestisce (a volte potrebbe essere un vantaggio);
• può essere difficile osservare le caratteristiche durante l’esecuzione e fare debug.
Riferimenti
• Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides – Design Patterns. Elementi per il riuso di software a oggetti — © Pearson Education Inc. / © Pearson Paravia Bruno Mondadori, 1995-2008, pp. 223-232