1 / 28

Génie Logiciel

Introduction au patrons de conception « Design patterns ». Génie Logiciel. Sommaire. Qu'est ce qu'un patron? Pourquoi les utiliser? Historique des patrons logiciels Types de patrons logiciels Types de patrons de conception Création, Structure, Comportement

eldon
Télécharger la présentation

Génie Logiciel

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Introduction au patrons de conception « Design patterns » Génie Logiciel Daniel.Bardou et Julie Dugdale @upmf-grenoble.fr

  2. Sommaire Qu'est ce qu'un patron? Pourquoi les utiliser? Historique des patrons logiciels Types de patrons logiciels Types de patrons de conception Création, Structure, Comportement Un exemple de patron de comportement Templates de patron Avantages et désavantages d'utiliser des patrons

  3. Qu'est ce qu'un patron de conception? L'utilisation actuelle vient des travaux de l'architecte Christopher Alexander Alexander a étudié les manières d'améliorer le processus de conception de bâtiments et des zones urbaines “Chaque patron est une règle en 3 parties, qui exprime une relation entre un certain contexte, un problème et une solution.” La définition habituelle d'un patron est : “Une solution à un problème dans un contexte.” • Les patrons peuvent être utilisés dans de nombreux domaines différents, y compris le développement logiciel.

  4. Pourquoi utiliser les patrons? "Concevoir un logiciel orienté-objet est difficile, et concevoir un logiciel orienté-objet réutilisable est encore plus difficile." - Erich Gamma Les concepteurs expérimentés réutilise des solutions qui ont fonctionné dans le passé Les systèmes orientés-objet bien structurés suivent des patrons récurrents pour les classes et objets Les patrons qui ont fonctionné dans le passé permettent d'être plus productif. Les conceptions qui en résultent sont plus flexibles et réutilisables.

  5. Devenir un champion aux échecs Apprendre à développer un bon logiciel est similaire à apprendre à bien jouer aux échecs. D'abord apprendre les règles Par exemple le nom des pièces, les mouvements permis, la géométrie de l'échiquier, etc. Puis apprendre les principes Par exemple la valeur relative de certaines pièces, la valeur stratégique des emplacements centraux, etc. Cependant, pour devenir un champion aux échecs, il faut étudier le jeu d'autres champions Ces jeux contiennent des patrons qui doivent être compris, mémorisés, puis appliqués de manière répétée. Il y a des centaines de patrons

  6. Devenir un champion du développement logiciel D'abord apprendre les règles c.a.d. les algorithmes, les structures de données, UML, les langages de programmation, etc. Puis apprendre les principes Par exemple la programmation structurée, la conception UML, la programmation orientée-objet, la programmation générique, etc. Mais pour devenir un champion de la conception logicielle, il est important d'étudier la conception d'autres champions Ces conceptions contiennent des patrons qui doivent être compris, mémorisés, et appliqués de manière répétée. Il y a des centaines de patrons

  7. Historique des patrons logiciels 1987 - Cunningham et Beck utilisent les idées d'Alexander pour développer un petit langage de patrons pour Smalltalk 1990 – Le Gang des 4 (« Gang of Four » : Gamma, Helm, Johnson and Vlissides) commence à travailler à la compilation d'un catalogue de patrons de conceptions 1991 - Bruce Anderson donne le premier workshop de Patrons au OOPSLA 1993 - Kent Beck et Grady Booch sponsorisent la première réunion de ce qui est maintenant connu comme le groupe Hillside http://www.hillside.net/ 1995 - Le Gang des 4 (GoF) publie le livre des Patrons de conception

  8. Types de patrons logiciels Riehle et Zullighoven dans “Understanding and Using Patterns in Software Development” mentionnent trois types de patrons logiciels 1. Patrons conceptuels Patrons dont la forme est décrite par les termes et concepts du domaine d'application 2. Patrons de conception Patrons dont la forme est décrite par les éléments de construction de conception logicielle (par exemple objets, classes, héritage et aggrégats)‏ 3. Patrons de programmation Patron dont la forme est décrite par les éléments de construction du langage de programmation

  9. Gang des 4 – Patrons de conception Le premier livre sur les patrons de conceptions était : ‘Design Patterns’ par Erich Gamma, Richard Helm, Ralph Johnson, et John Vlissides’ - Connus comme le Gang des 4 (‘Gang of Four’)‏ • Les patrons de conception sont : • « Descriptions d'objets et de classes communicantes qui sont adaptées à la résolution d'un problème général de conception dans un contexte particulier » • Chaque patron de conception décrit un ensemble d'objets et de classes communicants.

  10. Gang des 4 – Patrons de conception Dans leur livre, le Gang des 4 a défini 23 patrons de conception fondamentaux Les patrons sont regroupés en 3 catégories

  11. Classification du GoF pour les patrons de conception • But – (les 3 types de patrons de conception) 1. Patrons de création • Concernent le processus de la création d'objets • Les patrons de création aident à créer des objets pour vous, au lieu d’avoir à instancier les objets directement. 2. Patrons de structure • Concernent la composition de classes et d'objets • Les patrons de structure aident à composer des groupes d’objets en des structures plus larges, telles que des interfaces utilisateur complexes. 3. Patrons de comportement • Concernent l'interaction des classes et des objets • Les patrons de comportement aident à définir la communication entre les objets du système et définir comment le flux est controlé.

  12. Un exemple Un patron de comportement appelé ‘Chaine de responsabilité’ Le patron concerne la relation entre l'ensemble des objets et une requête. Le patron est utilisé quand plusieurs objets peuvent gérer une requête Le premier objet sur la chaine reçoit la requête : Il la résout ..ou la passe au prochain objet de la chaine

  13. Chaine de responsabilité Les restaurants travaillent de cette manière : Un client ne passe pas une requête directement au chef A la place, un client passe une requête à un serveur, qui peut la passer à un sous-chef (chaine de responsabilité)‏ Les participants à ce patron : client, un handler abstrait Des handlers concrets (fils du handler abstrait)

  14. Chaine de responsabilité Le client initie une requête Si un 'handler concret' peut gérer la requête, il le fait Sinon, il la passe vers le prochain handler Handler handleRequest()‏ Client Successeur HandlerConcret1 handleRequest()‏ HandlerConcret2 handleRequest()‏ La structure du patron de conception «chaine de responsabilité »

  15. Chaine de responsabilité Idée : libérer un objet du besoin de savoir quel autre objet remplit sa requête Employé handleRequest()‏ Client Successeur Serveur handleRequest()‏ Chef handleRequest()‏ Sous-Chef handleRequest()‏ Interface du handler abstrait pour gérer les requêtes Association reflexive : possibilité que le handler implémente le successeur – pour trouver leurs propres successeurs (représenté comme classe d'association)‏ Client: envoie une requête Le patron de conception de la 'chaine de responsabilité' appliqué au problème du restaurant Handler Concret

  16. Un autre exemple où le patron de la chaine de responsabilité peut être utilisé Considérons un aide contextuelle pour une interface utilisateur graphique L'utilisateur clique sur le bouton d'aide La requête d'aide est gérée par l'un objet parmi plusieurs objets de l'interface utilisateur, mais quel sera cet objet dépend du contexte et de la spécificité de l'aide disponible. Le problème est que l'objet qui fournit l'aide n'est pas connu par l'objet qui demande de l'aide.

  17. Chaine de responsabilité Utilisez la chaine de responsabilité quand : Plus d'un objet peut gérer une requête, et quel objet peut gérer une requête donnée n'est pas connu d'avance. Nous voulons passer une requête vers l'un de plusieurs objets sans spécifier le destinataire explicitement. L'ensemble des objets qui peuvent gérer une requête devrait être spécifié dynamiquement.

  18. D'autres patrons...

  19. Patrons de création Fabrique Une méthode dans une classe dérivée créé les instances associées Fabriqueabstraite Fabrique pour construire des objets liés Monteur Fabrique pour construire des objets complexes de manière incrémentale Prototype Fabrique pour cloner de nouvelles instances d'un prototype Singleton Fabrique pour n'avoir qu'une seule et unique instance

  20. Patrons de structure Adaptateur Un traducteur qui adapte une interface de serveur pour un client Pont Découpler l'interface d'une classe et son implémentation Objetcomposite Structure pour construire des aggrégats récursifs Décorateur Etend un objet de manière transparente Façade Façade simplifie l'interface pour un sous-système Poids-mouche De nombreux objets partagés efficacement Proxy Un objet est l'approximation d'un autre

  21. Patrons de comportement Chaine de responsabilité Requête déléguée au fournisseur de service responsable Commande Requête comme objet de première classe Interpréteur Interpréteur de langage pour une petite grammaire Itérateur Eléments d'un agrégat sont atteints séquentiellement Médiateur Médiateur coordonnes les interactions entre ses associés Memento Une photo qui capture et restaure des états d'objets Observateur Les observateurs sont mis au courant des changements des observés Etat Object dont le comportement dépend de son état Stratégie Abstraction pour la sélection d'un parmi plusieurs algorithmes Patron de méthode Algorithme avec des pas fournit par une classe dérivée Visiteur Opérations appliquée aux éléments d'une structure d'objet hétérogène

  22. Les parties essentielles des patrons de conception d'après le Gang of 4 Nom de patron Un nom court et parlant améliore la communication entre développeurs Problème Quel est le problème et le contexte pour lesquels nous utiliserions ce patron? Quelles sont les conditions pour l'utilisation de ce patron? Solution Une description des éléments constituant le patron de conception Conséquences Le pour et le contre de l'utilisation du patron Inclus les impacts sur la réutilisabilité, la portabilité et l'extensibilité

  23. Le template de patron du Gang des 4 Nom et classification du patron Un nom concis et le type du patron Intention Une explication courte de ce que fait le patron Alias Autres noms du patron Motivation Un scénario illustrant quand le patron serait utile Applicabilité Situations où le patron peut être utilisé

  24. Le template de patron du Gang des 4 (suite) Structure Une représentation graphique du patron Participants Les classes et objets participant au patron Collaborations Comment les participants interagissent pour gérer leurs responsabilités? Conséquences Le pour et le contre de l'utilisation du patron? Implémentation Conseils et techniques pour l'implémentation du patron

  25. Le template de patron du Gang des 4 (suite et fin) Echantillon de code Fragments de code pour un échantillon d'implémentation Utilisations connues Exemples du patron dans des systèmes réels Patrons liés Autres patrons qui sont liés de manière proche à ce patron

  26. Bénéfices des patrons de conception Capturent l'expertise et la rendent accessible à des non-experts Réduisent le temps de développement Facilitent la communication entre les développeurs en fournissant un langage commun Facilitent la réutilisation réussie de conceptions Améliorent la documentation de conception AméIiorent la compréhensibilité des conceptions

  27. Désavantages des patrons Les patrons sont simplistes, mais ils doivent être appliqués à votre problème Utiliser des patrons requiert la capacité de faire le lien entre un patron et votre problème! Les patrons sont validés par l'expérience, plutôt que par des tests automatiques

  28. Références Design Patterns: Elements of Reusable Object-Oriented Software, Gamma, Helm, Johnson and Vlissides, Addison-Wesley, 1995 Le Gang des 4! A lire! http://fr.wikipedia.org/wiki/Patron_de_conception

More Related