Patron de conceptionChain of Responsibility

Amira Hakim

Dept de Mathématique & InformatiqueUniversité de Souk-Ahras

1

UNIVERSITE MOHAMED CHERIF MESAADIASOUK-AHRAS

2

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).

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

Click

6

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.

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.

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.

Description

10

Séparer l’émetteur et le récepteur en donnant a plusieurs objets (dansun 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êteil 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.

Structure

11

Structure d’un objet typique

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.

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).

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.

Fin

15

Merci Pour votre Attention!