Patron de conception
Chain of Responsibility
Amira Hakim
Dept de Mathématique & Informatique
Université de Souk-Ahras
1
UN...
2
Motivation( Problématique )1/2
3
Considérons une fonction d'aide contextuelle pour une interface
graphique.
L'utilisateu...
Motivation( Problématique )2/2
4
Par conséquent, il vaut mieux organiser les information d'aide selon leur
généralité du p...
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 qu...
intention
8
Eviter de coupler l’émetteur d’une requête avec son récepteur en
donnant une chance a plusieurs autres objets ...
Utilité de chain of responsibility
9
Plus d’un objet peut traiter la requête ,mais celui qui vas vraiment gérer
cette requ...
Description
10
Séparer l’émetteur et le récepteur en donnant a plusieurs objets (dans
un certain ordre) une chance a gére...
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 tra...
Conséquences
13
Avantages:
Découplement ou séparation de l’émetteur du récepteur.
Plus de flexibilité.
Les émetteurs ne...
Patrons connexes
14
Le patron chaîne de responsabilité est souvent appliquée en
conjonction avec le patron composite.
D’où...
Fin
15
Merci Pour votre Attention!
Prochain SlideShare
Chargement dans…5
×

Patron de conception Chain of Responsibility

581 vues

Publié le

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.

Publié dans : Ingénierie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
581
Sur SlideShare
0
Issues des intégrations
0
Intégrations
7
Actions
Partages
0
Téléchargements
16
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Patron de conception Chain of Responsibility

  1. 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. 2
  3. 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. 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. 5 Click
  6. 6. 6
  7. 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. 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. 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. 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. 11. Structure 11 Structure d’un objet typique
  12. 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. 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. 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. 15. Fin 15 Merci Pour votre Attention!

×