Le design pattern "Chain of Responsibility" est selon GOF(the Gang Of Four) un patron de conception comportemental. Son intention est d'éviter de coupler l’émetteur d’une requête avec son récepteur en donnant une chance a plusieurs autres objets de gérer cette requête. La chaine d’objets récepteurs passent la requête jusqu’a ce qu’un objet gère cette dernière.

1. Patron de conception
Chain of Responsibility
Amira Hakim
Dept de Mathématique & Informatique
Université de Souk-Ahras
1
UNIVERSITE MOHAMED CHERIF MESAADIA
SOUK-AHRAS

2. 2

3. Motivation( Problématique )1/2
3
Considérons une fonction d'aide contextuelle pour une interface
graphique.
L'utilisateur peut obtenir des informations d'aide sur une partie de
l'interface en cliquant simplement dessus.
L'aide qui est fournie dépend de la partie de l'interface concernée et
aussi de son contexte.
Par ex , un bouton d’une boite de dialogue doit avoir des informations
d’aides différentes de celui d’un bouton de l’accueil de l’application.
Si aucune information d'aide existe pour cette partie de l'interface,
alors le système d'aide devrait afficher un message d'aide plus générale
sur le contexte immédiat(la boîte de dialogue dans son ensemble, par
ex).

4. Motivation( Problématique )2/2
4
Par conséquent, il vaut mieux organiser les information d'aide selon leur
généralité du plus spécifique au plus général.
Une demande d'aide est assurée par l'un des plusieurs objets d'interface
utilisateur ,dont chacun dépend du contexte et spécificité du help.
Le problème ici est que l'objet qui fournit finalement l'aide n’est pas
connu de façon explicite à l'objet (par exemple, le bouton) qui initie la
demande d'aide.

5. 5
Click

6. 6

7. De quoi a-t-on besoin?
7
Nous avons besoin d'un moyen de découpler le bouton qui déclenche la
demande d'aide des objets qui pourraient fournir des informations
d'aide.
Le patron Chain of Responsibility définit comment cela se passe.

8. intention
8
Eviter de coupler l’émetteur d’une requête avec son récepteur en
donnant une chance a plusieurs autres objets de gérer cette requête.
La chaine d’objets récepteurs passent la requête jusqu’a ce qu’un objet
gère cette dernière.

9. Utilité de chain of responsibility
9
Plus d’un objet peut traiter la requête ,mais celui qui vas vraiment gérer
cette requête n’est pas connu a l’avance.
Lorsqu’on veut attribuer la requête a un objet spécifique sans spécifier
le récepteur explicitement.
L’ensemble d’objets qui peuvent traiter la requête doit être spécifié
dynamiquement.

10. Description
10
Séparer l’émetteur et le récepteur en donnant a plusieurs objets (dans
un certain ordre) une chance a gérer la requête.
La requête est passée jusqu’a ce qu’un objet décide de la prendre en
charge(Handling the request ).
Le 1er objet de la chaine reçoit la requête soie:
il gère cette requête
il fait passer la requête a son successeur dans la chaine .
L’objet qui envoi la requête n’a aucune connaissance explicite de celui
qui va la traiter.

11. Structure
11
Structure d’un objet typique

12. Participants
12
Client: initialise une requête a un ConcreteHandler dans une chaine.
Handler: définit l’interface de traitement de requêtes. Il peut ainsi
implémenter des liens de ces successeurs.
ConcreteHandler: traite la requête dont il est responsable, ou passe la
requête a son successeur.

13. Conséquences
13
Avantages:
Découplement ou séparation de l’émetteur du récepteur.
Plus de flexibilité.
Les émetteurs ne sont pas obligés de savoir les handlers de leurs
requêtes.
Inconvénient:
le client ne peut pas explicitement préciser qui gère une demande.
Aucune garantie sur le traitement de la requête(demande tombe sur
fin de chaîne).

14. Patrons connexes
14
Le patron chaîne de responsabilité est souvent appliquée en
conjonction avec le patron composite.
D’où, le parent d'un composant peut agir comme son
successeur.

15. Fin
15
Merci Pour votre Attention!