Pattern Chain Of Responsibility

Summary Un design pattern che elimina la dipendenza dell'oggetto che effettua la richiesta da quello che la soddisfa e permette a più oggetti di soddisfarla.

Conosciuto anche come

Call objects?

No ha altri nomi.

Intento

Il design pattern Chain Of Responsibility disaccoppia l'oggetto che effettua una richiesta dal destinatario dando a più oggetti la possibilità di rispondere. Gli oggetti candidati a rispondere sono concatenati tra loro e passano la richiesta lungo la catena sino a quando un oggetto la gestisce.

La catena di oggetti Handler è determinata a run-time quindi questo design pattern è classificato rispetto allo scopo (vedi ClassificazioneDeiDesignPattern#ClassiOggetti) come rivolto agli oggetti. Rispetto al fine questo design pattern è classificato tra i ClassificazioneDeiDesignPattern#Comportamentali .

Diagramma UML

Un'altro diagramma equivalente qui e qui .

Motivazione

In alcuni sistemi c'è la necessità di cambiare in modo flessibile, a run-time, l'oggetto destinato a gestire una richiesta o la necessità di gestire nuove richieste aggiungendo nuovi oggetti in grado di soddisfarle oppure cambiare la precedenza con cui più oggetti sono chamati a soddisfare una richiesta.

Ci può essere inoltre la convenienza di disaccoppiare l'oggetto che invia la richiesta da quello che la soddisfa in modo che il primo non debba conoscere il secondo.

Esempi d'uso in .NET

Un esempio di applicazione di questo design pattern in .NET è la catena di HttpModule attraverso cui HttpApplication fa passare la richiesta che arriva dal client. ASP.NET fornisce una serie di HttpModule standard (FormsAuthenticationModule, PassportAuthenticationModule, WindowsAuthenticationModule, SessionStateModule, ...) elencati nella sezione <httpModules> del file machine.config. Questa infrastruttura permette di aggiungere, togliere o cambiare l'ordine degli HttpModule standard oppure di inserirci degli HttpModule personalizzati che implementano IHttpModule (ad esempio per gestire gli errori run-time non catturati e farne il log o implementare una autenticazione mista Windows/Form). Ogni HttpModule passa la richiesta a quello successivo sia che elabori la richiesta sia che non lo facia niente mentre nel design pattern Chain Of Responsibility il primo oggetto che gestisce la richiesta interrompe la catena.

Un altro esempio è nell'infrastruttura del Remoting dove una richiesta inviata dal client in un application domain arriva al server in un altro application domain per un certo canale (per esempio HttpChannel o TcpChannel) passando attraverso diversi "message sink" concatenati (per esempio SoapClientFormatterSink ~~> ...~~ > HttpClientTransportSink). Questa infrastruttura permette di comporre un canale con diversi "message sink" e con la possibilità di aggiungere dei "message sink" personalizzati (IClientChannelSink) tra gli elementi standard della catena per fornire servizi aggiuntivi (logging, criptazine, replicazione, load-balancing, etc.). Ogni "message sink" passa il messaggio a quello successivo sia che lo elabori sia che non lo modifichi mentre nel design pattern Chain Of Responsibility il primo oggetto che gestisce la richiesta interrompe la catena.

Note sulla implementazione in .NET

Del codice .NET di esempio è disponibile qui .

Relazione con altri design pattern

Il design pattern Chain of Responsibility è spesso usato insieme al PatternComposite in cui il padre di un componente agisce come successore nella catena di oggetti.

Inoltre il design pattern Chain of Responsibility può usare il PatternCommand per rappresentare la richiesta fatta dall'oggetto.

Vedi la mappa della RelazioneTraDesignPattern.

Approfondimenti

Quando l'oggetto che effettua la richiesta conosce già quale oggetto dovrà servirla oppure quando esiste un unico oggetto in grado di soddisfare una richiesta (ossia non è necessaria la flessibilità in futuro di inserire diversi oggetti nella catena per una data richiesta), questo design pattern non è utile.

Questo design pattern non garantisce l'esistenza di almeno un oggetto che gestisce una richiesta, è conveniente mettere come ultimo nodo della catena un oggetto che riceve le richieste non soddisfatte e le tratta opportunamente (ad esempio sollevando un errore invece che lasciarle andar perse).

E' possibile utilizzare delle classi base per tipizzare la strutturazione della catena ossia porre dei vincoli sul tipo di oggetto che può essere posto in un punto della catena.

Domande di approfondimento

Che differenza c'è tra questo design pattern e il PatternDecorator? E con una lista concatenata?
Se due o più design pattern possono avere una medesima implementazione, questo aiuta a capire quando vanno applicati ad un disegno?
Che similitudini ha questo design pattern con PatternCommand, PatternMediator, and PatternObserver? E che differenze?

Link

VediAnche CatalogoDeiDesignPattern