Design Patterns Java

8,690 views

Published on

Design patterns
Observer, Decorateur, State, template methode

Published in: Technology, Business
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,690
On SlideShare
0
From Embeds
0
Number of Embeds
40
Actions
Shares
0
Downloads
974
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide
  • Design Patterns Java

    1. 1. Design Patterns JAVA Conception d’applications objet B.Vinot
    2. 2. Contenu du cours <ul><li>Introduction aux DP </li></ul><ul><li>Principes fondamentaux de conception </li></ul><ul><ul><li>Les patterns GRASS </li></ul></ul><ul><ul><li>Ouverture-Fermeture (OCP) </li></ul></ul><ul><ul><li>Inversion des dépendances (DIP) </li></ul></ul><ul><ul><li>Substitution de Liskov (LSP) </li></ul></ul><ul><ul><li>Séparation des interfaces (ISP) </li></ul></ul><ul><li>Méthodes de DVP et Processus </li></ul><ul><ul><li>Up – XP </li></ul></ul><ul><ul><li>Tests et Refactoring </li></ul></ul><ul><li>Les design patterns </li></ul><ul><ul><li>Les DP du GOF (23) </li></ul></ul><ul><ul><ul><li>Comportement (11) </li></ul></ul></ul><ul><ul><ul><li>Structure (7) </li></ul></ul></ul><ul><ul><ul><li>Création (5) </li></ul></ul></ul><ul><ul><li>Autres Patterns </li></ul></ul><ul><ul><ul><li>Les Patterns d'analyse </li></ul></ul></ul><ul><ul><ul><li>Le Raii </li></ul></ul></ul><ul><li>Organisation </li></ul><ul><ul><li>MVC </li></ul></ul><ul><ul><li>Les frameworks </li></ul></ul><ul><ul><li>Les composants </li></ul></ul><ul><ul><li>Les packages </li></ul></ul><ul><ul><li>Métriques </li></ul></ul>exercices
    3. 3. Pourquoi faire de l'objet(1) ?
    4. 4. Pourquoi faire de l'objet(2) ?
    5. 5. Introduction aux Design Patterns Les Patterns GRASS General ResponsabilityAssignement Software Patterns
    6. 6. Les Patterns : Introduction <ul><li>Naissance des patterns : Les patterns furent utilisés bien avant que les systèmes d’informations modernes n’apparaissent, dans d’autres disciplines comme la construction et l’architecture de bâtiments. </li></ul><ul><li>1987, Beck et Cunningham définissent des patterns pour interfaces utilisateurs. </li></ul><ul><li>1994 : Design Patterns : Elements of reusable object oriented software Gof pour Gang of Four ( Gamma, Helm, Johnson et Vlissides) </li></ul><ul><li>Craig Larman décrit des modèles de conception plus intuitifs : les Patterns GRASP : General Responsability Assignement Software Patterns, ou patterns généraux d’affectation des responsabilités. </li></ul>
    7. 7. Les Patterns : Définition <ul><li>Un design pattern est un modèle de conception. Au fur et à mesure des développements, des principes généraux répétitifs sont remarqués, et des solutions courantes sont identifiées. En formalisant celles-ci, sous la forme de la présentation d’un problème de conception, et de la solution pour le résoudre, on obtient un design Pattern. </li></ul><ul><li>Un design pattern doit répondre à certains aspects essentiels : </li></ul><ul><ul><li>Un pattern a un nom évocateur, qui représente bien l’essence même de son existence. Exemple : le pattern GoF « Singleton » </li></ul></ul><ul><ul><li>Un pattern résout un problème . Exemple : une classe ne peut avoir qu’une et une seule instance disponible. </li></ul></ul><ul><ul><li>Un pattern fourni une solution-génie (voir le pattern singleton plus loin) </li></ul></ul><ul><ul><li>Un pattern doit être expliqué ( documentation-uml ) </li></ul></ul>
    8. 8. Exemple : Les Patterns Grasp <ul><li>C’est presque du bon sens </li></ul><ul><ul><li>L’expert (affectation des responsabilités) </li></ul></ul><ul><ul><li>Le créateur </li></ul></ul><ul><ul><li>Faible couplage </li></ul></ul><ul><ul><li>Forte cohésion </li></ul></ul><ul><ul><li>Contrôleur </li></ul></ul>
    9. 9. Le pattern GRASP : Expert <ul><li>Qui fait quoi : </li></ul><ul><li>le modèle Expert est un pattern relativement intuitif, qui en général, est respecté par le bon sens du concepteur. Il s’agit tout simplement d’affecter à une classe les responsabilités correspondants aux informations dont elle dispose intrinsèquement (qu’elle possède) ou non ( objets de collaborations ). </li></ul><ul><ul><li>on ne peut exiger d’un réfrigérateur qu’il fasse radiateur et range-disques </li></ul></ul><ul><ul><li>Donner des définitions (c'est très difficile) </li></ul></ul><ul><ul><li>int i; // variable i entière </li></ul></ul>
    10. 10. Le pattern GRASP : Créateur <ul><li>Qui crée qui? : </li></ul><ul><li>Ce pattern consiste en la détermination de la responsabilité de la création d’une instance d’une classe par une autre. </li></ul><ul><ul><li>Une classe A agrége des instances de la classe B </li></ul></ul><ul><ul><li>Une classe A contient des instances de la classe B </li></ul></ul><ul><ul><li>Une classe A utilise des instances d’une classe B </li></ul></ul><ul><ul><li>Une classe A possède les données nécessaires à l’initialisation des instance de classe B, etc.… </li></ul></ul><ul><ul><li>Variables globales! </li></ul></ul><ul><ul><li>Notion de configurateur </li></ul></ul><ul><ul><li>Déléguer la fabrication à qq d’autre! </li></ul></ul><ul><ul><li>Persistance (JDBC,DAO) </li></ul></ul>
    11. 11. Le pattern GRASP : Couplage <ul><li>Le couplage exprime la relation étroite qu’un élément (Classe, Système ou sous système) entretien avec un ou des autres éléments. Un élément faiblement couplé ne possède pas ou peu de dépendances vis a vis d’autres éléments. </li></ul><ul><li>Les objets sont couplés (paresseux) </li></ul><ul><li>Un objet qui est connu de personne est inutile. </li></ul><ul><li>Un objet qui connaît personne ne fait pas grand chose (sauf Utility) </li></ul><ul><li>Parler à des classes abstraites plus tôt qu’à des classes concrètes </li></ul>
    12. 12. Le pattern GRASP : Cohésion <ul><li>Esprit de famille </li></ul><ul><li>La cohésion mesure le degré de spécialisation des responsabilités d’un composant / classe. </li></ul><ul><li>La cohésion médiocre altère la compréhension, la réutilisation, la maintenabilité et subit toute sorte de changements. </li></ul><ul><li>Exception pour Corba, RMI, …..(pb de granularité) </li></ul>
    13. 13. Le pattern GRASP : Contrôleur <ul><li>Le contrôleur contrôle. Il est entre la vue et les entités (MVC) </li></ul><ul><li>Une classe Contrôleur doit être crée si elle répond à l’un des cas suivants </li></ul><ul><ul><li>La classe représente une contrôleur de façade , c’est à dire l’interface d’accès à l’ensemble d’un système. </li></ul></ul><ul><ul><li>La classe représente le scénario d’un cas d’utilisation . On le nomme en général « Session », et est chargé de traiter tous les événements systèmes contenus dans un scénario de cas d’utilisation. </li></ul></ul><ul><ul><li>Un contrôleur contient : </li></ul></ul><ul><ul><ul><li>Ce qui ne concerne pas la vue </li></ul></ul></ul><ul><ul><ul><li>Ce qui ne concerne pas les entités (Expert) </li></ul></ul></ul>
    14. 14. Principes fondamentaux de conception Ouverture-Fermeture OCP Inversion des dépendances DIP Substitution de Liskov LSP Séparation des interfaces ISP
    15. 15. Les objectifs du DESIGN <ul><li>Éviter les phénomènes de dégénérescence de l'application </li></ul><ul><li>Du point de vue du design, trois risques principaux pénalisent les activités de développement : </li></ul><ul><ul><li>La rigidité : chaque évolution est susceptible d'impacter de nombreuses parties de l'application  Extensibilité. </li></ul></ul><ul><ul><li>La fragilité : la modification d'une partie de l'application peut provoquer des erreurs  Robustesse </li></ul></ul><ul><ul><li>L' immobilité : il est difficile d'extraire une partie de l'application pour la réutiliser dans une autre application. </li></ul></ul><ul><ul><ul><li> Réutilisation </li></ul></ul></ul>
    16. 16. Gestion des évolutions et des dépendances entre classes <ul><li>Principe d’ouverture/fermeture Open-Closed Principle (OCP) Touche pas à mon code </li></ul><ul><li>Principe de substitution de Liskov Liskov Substitution Principle (LSP) Les enfants doivent respecter le contrat </li></ul><ul><li>Principe d’inversion des dépendances Dependency Inversion Principle (DIP) Utiliser des Interfaces </li></ul><ul><li>Principe de séparation des interfaces Interface Segregation Principle (ISP) Diviser les interfaces </li></ul>
    17. 17. Exemple : utilisation de la délégation abstraite ( OCP ) <ul><li>A gère les cas c1 et c2. Si un nouveau cas c3 doit être géré, il faut modifier le code de A en conséquence : </li></ul>
    18. 18. L’application de l’OCP est un choix stratégique ( OCP ) <ul><li>L'OCP est un principe incontournable lorsque l'on parle de flexibilité du code. Par contre, une erreur classique consisterait à vouloir ouvrir/fermer toutes les classes de l'application en vue d'éventuels changements. </li></ul><ul><li>Cela constitue une erreur dans la mesure où la mise en oeuvre de l'OCP impose une certaine complexité qui devient néfaste si la flexibilité recherchée n'est pas réellement exploitée. </li></ul><ul><li>Il convient donc d'identifier correctement les points d'ouverture/fermeture de l'application, en s'inspirant : </li></ul><ul><ul><li>des besoins d'évolutivité exprimés par le client, </li></ul></ul><ul><ul><li>des besoins de flexibilité pressentis par les développeurs, </li></ul></ul><ul><ul><li>des changements répétés constatés au cours du développement . </li></ul></ul><ul><li>La mise en oeuvre de ce principe reste donc une affaire de bon sens. </li></ul>
    19. 19. Exemple : ( OCP ) Personne nom : string age : int Personne(n : string, a : int) Appl1 Appl2 BD Appl3 Avec adr <ul><li>Rajouter un attribut </li></ul><ul><ul><li>Rajouter un constructeur </li></ul></ul><ul><ul><li>Rajoute un paramètre au constructeur </li></ul></ul><ul><li>Faire une nouvelle classe PersonneAdr </li></ul><ul><ul><li>Rajouter une méthode getAdr même ds Personne </li></ul></ul>ID nom age
    20. 20. Exemple : ( OCP ) Solution Appl1 Appl2 Personne nom : string age : int Personne(n : string, a : int) GetAdresse() : string PersonneDomicilee adresse : string PersonneDomiciliee(n : string, a : int, adr : string) GetAdresse() : string SetAdresse(p : string) : void Rend une chaîne vide: Appl3 peut alors utiliser des Personnes <ul><li>Jouer sur les méthodes plus tôt que sur les attributs </li></ul><ul><li>Les gains : </li></ul><ul><li>2 versions dans le même exécutable </li></ul><ul><li>pas besoin de faire de VNR (faites la quand même) </li></ul>Appl3
    21. 21. Principes de substitution de LISkOV ( LSP ) <ul><li>Pour prétendre à l'héritage, une sous-classe doit être conçue de sorte que ses instances puissent se substituer à des instances de la classe de base partout où cette classe de base est utilisée. </li></ul><ul><li>Hériter d’une interface </li></ul><ul><li>En insistant sur cette approche de l'héritage, le principe de substitution s'oppose à une pratique répandue dans laquelle l'héritage est mis en oeuvre pour factoriser du code entre plusieurs classes. </li></ul>
    22. 22. Principes de substitution de LISkOV ( LSP ) : exemple class Rectangle { int longueur, largeur; public: virtual void setValeur(int long, int larg) {longueur = long; largeur = larg; }; class Carre : public Rectangle { public: virtual void setValeur(int long, int larg) { if (long != larg) throw std::exception(« long !=larg&quot;); super.setValeur(long, larg); } }; void utiliserRectangle(int lng) { leRectangle.setValeur(lng, lng * 2); assert(leRectangle.getArea() == (length*length*2)); Que se passe-t-il si le Rectangle est un carré? Héritage<>Composition
    23. 23. Principes d’inversion des dépendances ( DIP ) <ul><li>Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects &quot;métier&quot;) sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication) :&quot; Le passage à l'abstrait est valorisé&quot; </li></ul>
    24. 24. Principes d’inversion des dépendances ( DIP ) <ul><li>Cela paraît naturel au premier abord mais pose en réalité deux problèmes essentiels : </li></ul><ul><ul><li>Les modules de haut niveau doivent être modifiés lorsque les modules de bas niveau sont modifiés. </li></ul></ul><ul><ul><li>Il n'est pas possible de réutiliser les modules de haut niveau indépendamment de ceux de bas niveau. En d'autres termes, il n'est pas possible de réutiliser la logique d'une application en dehors du contexte technique dans lequel elle a été développée. </li></ul></ul><ul><li>La relation de dépendance doit être inversée : </li></ul><ul><ul><li>les modules de bas niveau doivent se conformer à des interfaces définies et utilisées par les modules de haut niveau . </li></ul></ul>
    25. 25. L’abstraction comme technique d’inversion des dépendances ( DIP ) <ul><li>Considérons deux classes A et B, A utilisant B comme indiqué sur le schéma ci-dessous : </li></ul>Pour inverser la dépendance de A vers B, on introduit une classe d'interface I dont dérive B comme suit :
    26. 26. Principes de séparation des interfaces ( ISP ) <ul><li>Pollution d'interface par agrégation de services </li></ul><ul><ul><li>On retrouve dans la plupart des designs quelques classes qui rendent plusieurs services simultanément, comme l'illustre le schéma ci-dessous : </li></ul></ul>
    27. 27. Principes de séparation des interfaces ( ISP ) <ul><li>L'inconvénient de ce genre de cas est que tous les clients ont une visibilité sur tous les services rendus par la classe : </li></ul><ul><ul><li>Chaque client voit une interface trop riche dont une partie ne l'intéresse pas, </li></ul></ul><ul><ul><li>Chaque client peut être impacté par des changements d'une interface qu'il n'utilise pas. </li></ul></ul><ul><li>Solution : séparation des services de l'interface </li></ul><ul><ul><li>Le principe de séparation des interfaces stipule que chaque client ne doit &quot;voir&quot; que les services qu'il utilise réellement </li></ul></ul>
    28. 28. Principes de séparation des interfaces ( ISP )
    29. 29. Techniques de séparation ( ISP ) <ul><li>Il existe deux techniques principales de mise en pratique de l'ISP : </li></ul><ul><ul><li>L'héritage multiple, </li></ul></ul><ul><ul><li>Le Design Pattern &quot;Adapter&quot;. </li></ul></ul>
    30. 30. Séparation par héritage multiple ( ISP ) <ul><li>Dans cette approche chaque service est représenté par une classe d'interface dont dérive la classe qui implémente les services. Les clients ne voient les services qu'au travers de ces classes d'interface comme le montre le schéma suivant : </li></ul>
    31. 31. Séparation par adaptateur ( ISP ) <ul><li>Lorsque l'héritage multiple n'est pas possible, les services peuvent être représentés par des classes d'adaptation : </li></ul>
    32. 32. Processus Objet UP XP-Agile Winston Royce. Managing the Development of Large Software Systems . 1970
    33. 33. UP: Caractéristiques essentielles <ul><li>Caract é ristiques essentielles du processus unifi é : </li></ul><ul><li>- Le processus unifi é est à base de composants , </li></ul><ul><li>Le processus unifi é utilise le langage UML </li></ul><ul><ul><li>(ensemble d'outils et de diagramme), </li></ul></ul><ul><li>- Le processus unifi é est pilot é par les cas d ’ utilisation , </li></ul><ul><li>Centr é sur l ’ architecture </li></ul><ul><ul><li>(plate-forme, performances, r é utilisation, ind é pendante </li></ul></ul><ul><ul><li>des UC, Y, … ) </li></ul></ul><ul><li>- It é ratif et incr é mental . </li></ul>UP  RUP  XUP
    34. 34. UP & les modèles UML (1)
    35. 35. UP & les modèles UML (2) Modèle des cas d’utilisation Expose les cas d’utilisation et leurs relations avec les utilisateurs Modèle d’analyse Détaille les cas d’utilisation et procède à une première répartition du comportement du système entre divers objets Modèle de conception Définit la structure statique du système sous forme de sous système, classes et interfaces ; Définit les cas d’utilisation réalisés sous forme de collaborations entre les sous systèmes les classes et les interfaces Modèle d’implémentation Intègre les composants (code source) et la correspondance entre les classes et les composants Modèle de test Décrit les cas de test vérifiant les cas d’utilisation Modèle de déploiement Définit les nœuds physiques des ordinateurs et l’affectation de ces composants sur ces nœuds. Modèle d'architecture Description de l’architecture (réutilisable)
    36. 36. UP & L'organisation matricielle
    37. 37. Processus Objet XP-Agile Extrem programing La programmation extrême Les processus agiles
    38. 38. Pourquoi une nouvelle Méthode ? Les approches classiques de développement type &quot;waterfall&quot;, basées sur la fameuse Séquence spécification / conception / réalisation / validation, souffrent de problèmes chroniques : <ul><li>Les spécifications sont définies au début du projet, alors qu'on en sait encore peu sur le sujet, </li></ul><ul><li>Les spécifications différencient rarement ce qui est important de ce qui ne l'est pas, </li></ul><ul><li>L'application se rigidifie progressivement en un produit &quot;final&quot; souvent difficile à faire évoluer et à maintenir, </li></ul><ul><li>Les activités sont compartimentées en fonction des spécialités des développeurs, ce qui pose des problèmes de répartition des tâches et limite la circulation des connaissances dans l'équipe. </li></ul>
    39. 39. Les méthodes agiles <ul><li>Année 80 : RAD (100 jours) </li></ul><ul><li>Année 90 : XP (Chrysler) et DSDM (Angleterre) </li></ul><ul><ul><li>( Dynamic Software Development Method ) </li></ul></ul><ul><li>2001 : Le manifeste Agile </li></ul><ul><ul><li>individus et interactions plutôt que processus et outils </li></ul></ul><ul><ul><li>développement logiciel plutôt que documentation exhaustive </li></ul></ul><ul><ul><li>collaboration avec le client plutôt que négociation contractuelle </li></ul></ul><ul><ul><li>ouverture au changement plutôt que suivi d’un plan rigide </li></ul></ul>
    40. 40. Les valeurs d' XP (1) <ul><li>Communication </li></ul><ul><li>XP intègre réellement le client au projet pour qu'il définisse mieux ses besoins, arbitre les priorités et apporte ses connaissances métier à l'équipe. </li></ul><ul><li>XP fait travailler tous les développeurs ensemble et les fait participer à toutes les activités du développement, créant ainsi une réelle dynamique d'équipe. </li></ul><ul><li>XP rend accessible à tous les intervenants l'ensemble des indicateurs d'avancement du projet. </li></ul><ul><li>Feedback </li></ul><ul><li>XP fournit des livraisons régulières au client pour lui permettre d'affiner et de compléter la définition de ses besoins à partir de données concrètes. </li></ul><ul><li>XP met en place des batteries de tests d'acceptation qui mesurent concrètement l'avancement des développements. </li></ul><ul><li>XP met en place des batteries de tests unitaires qui indiquent rapidement si le code fonctionne et qui détectent instantanément toute régression. </li></ul>
    41. 41. Les valeurs d' XP (2) <ul><li>Simplicit é </li></ul><ul><li>XP s'assure que seules les fonctionnalit é s demand é es par le client sont impl é ment é es. </li></ul><ul><li>XP maintient un design et un code toujours aussi simples que possible pour rester ouvert au changement et conserver une grande vitesse de d é veloppement tout au long du projet. </li></ul><ul><li>Courage </li></ul><ul><li>XP donne au jour le jour une transparence maximale sur l' é tat d'avancement r é el du projet. </li></ul><ul><li>XP s'attaque aux probl è mes d è s qu'ils se pr é sentent, en autorisant des retours en arri è re s'ils sont n é cessaires. </li></ul>
    42. 42. Binôme (1) <ul><li>Binôme </li></ul><ul><ul><li>Bien perçu des programmeurs </li></ul></ul><ul><ul><li>Garantit l’homogénéité du code, le respect des règle de codage </li></ul></ul><ul><ul><li>Responsabilité et connaissance collective du code </li></ul></ul><ul><ul><li>Facilite la communication (moins de situation de blocage) </li></ul></ul><ul><ul><li>Pousse à bien faire (Motivation et satisfaction) </li></ul></ul><ul><ul><li>Phase d'adaptation de 2 semaines </li></ul></ul><ul><ul><li>Ne pas accepter ceux qui refusent </li></ul></ul><ul><ul><li>Le code est de meilleur qualité (ils pensent + aux cas particuliers) </li></ul></ul><ul><li>Stand up meeting chaque soir </li></ul><ul><ul><li>Faire tourner les binômes </li></ul></ul><ul><ul><li>Répartition des compétences </li></ul></ul>
    43. 43. Binôme (2) <ul><li>Exploration d’un problème (Spike - CrcCards) </li></ul><ul><li>Nom des objets (bonne compréhension) </li></ul><ul><ul><li>Prendre le temps de bien le faire (Métaphore local) </li></ul></ul><ul><li>Documenter le code </li></ul><ul><ul><li>Pas de documentation mais un code bien commenté (Déclaration) </li></ul></ul><ul><li>Espace de travail </li></ul><ul><ul><li>Espace de développement central </li></ul></ul><ul><ul><li>Bureautique en périphérie </li></ul></ul><ul><ul><li>Grande table de réunion dans le bureau </li></ul></ul><ul><ul><li>Grand écrans pour le développement </li></ul></ul><ul><ul><li>Tout le monde se voit (mobilier spécifique?) </li></ul></ul>
    44. 44. TU <ul><li>Tests unitaires </li></ul><ul><ul><li>Aide à la conception détaillé </li></ul></ul><ul><ul><li>Systématiquement avant le code (inhabituelle) </li></ul></ul><ul><ul><li>Ne doit pas passer au début (Iconoclaste?) </li></ul></ul><ul><ul><li>Ne pas développer plus que ce qui est nécessaire pour le test </li></ul></ul><ul><ul><li>Auto-vérifiant (18000 tests passés en 15 mn-tests passés de 15 mn </li></ul></ul><ul><ul><ul><li>À 20 secondes) </li></ul></ul></ul><ul><ul><li>Tous les tests de tous les modules doivent passer sans erreur avant </li></ul></ul><ul><ul><ul><li>d’intégrer le code </li></ul></ul></ul><ul><ul><li>Super aide à la non régression, au changement de conception et </li></ul></ul><ul><ul><ul><li>au remaniement </li></ul></ul></ul><ul><ul><li>Cela peut être mis en œuvre hors de XP </li></ul></ul>
    45. 45. La Planification <ul><li>La planification collective en début d’incrément (Une journée) </li></ul><ul><ul><li>Incrément de trois semaines </li></ul></ul><ul><ul><li>Lecture et explications des user stories (cas d’utilisation) </li></ul></ul><ul><ul><li>Grandes lignes de la conception </li></ul></ul><ul><ul><li>Définition et évaluation des tâches </li></ul></ul><ul><li>Évaluation en temps idéal + Load factor </li></ul><ul><ul><li>Évaluation en deux groupes. Le minimum est choisi si aucune </li></ul></ul><ul><ul><ul><li>difficulté n’a été oubliée. </li></ul></ul></ul>
    46. 46. Conditions d’application <ul><li>Il faut : </li></ul><ul><li>Une équipe qui s’entende bien et réduite (12 max) </li></ul><ul><li>Développement mono site </li></ul><ul><li>Programmation par composants </li></ul><ul><li>Que le client participe et adhère </li></ul><ul><li>Il ne faut pas: </li></ul><ul><li>Une spécification complète et détaillée du futur système </li></ul><ul><li>Mesurer la qualité de la documentation au poids </li></ul>
    47. 47. Les principes de base <ul><li>Seul le code source fait foi, il possède une odeur </li></ul><ul><li>L’important c’est le programmeur </li></ul><ul><li>Faire le plus simple possible </li></ul><ul><li>Restructurer dès que nécessaire </li></ul><ul><li>Pratiquer la programmation par paire </li></ul><ul><li>Les spécifications sont des « histoires d’utilisateurs » </li></ul><ul><li>La planification est un jeu </li></ul><ul><li>Livrer fréquemment </li></ul><ul><li>Tester encore, toujours et tout le temps </li></ul><ul><li>Être courageux </li></ul>
    48. 48. histoires d’utilisateurs <ul><li>Des descriptions rédigées par les utilisateurs (clients) </li></ul><ul><li>Pour chaque histoire : </li></ul><ul><ul><li>le client donne : </li></ul></ul><ul><ul><ul><li>Priorité </li></ul></ul></ul><ul><ul><ul><li>Tests d’acceptation </li></ul></ul></ul><ul><ul><li>Les développeurs : </li></ul></ul><ul><ul><ul><li>Estimation de la charge de la réalisation </li></ul></ul></ul><ul><ul><ul><ul><li>(l’histoire peut être découpée en tâches) </li></ul></ul></ul></ul>Une histoire est une unité de livraison RMQ : Une histoire est un très gros use case
    49. 49. La planification est un jeu XP tente de désamorcer les conflits Un vrai dialogue Client Développeur <ul><li>Définition des itérations : </li></ul><ul><li>Histoires avec les priorités </li></ul><ul><li>Proposer des choix au client </li></ul>
    50. 50. Être courageux <ul><li>Standup meeting </li></ul><ul><li>Choisir des tâches que l’on ne sait pas faire </li></ul><ul><li>Accepter d’expliquer aux autres ce que l’on sait </li></ul><ul><li>S’arrêter de développer pour faire du refactoring </li></ul><ul><li>Accepter de ne pas être responsable, alors qu’on est plus fort </li></ul><ul><li>Ne pas avoir les yeux plus gros que le ventre </li></ul>
    51. 51. Déroulement Scrum
    52. 52. Processus Objet Tests Refactoring
    53. 53. Test et Junit
    54. 54. Junit
    55. 55. Junit : Ecrire le test package com.moi.test.junit; import junit.framework.TestCase; public class MaClasseTest extends TestCase {    private MaClasse maClasse = null;    public MaClasseTest(String arg0) {          super(arg0);    }    public static void main(String[] args) {          junit.swingui.TestRunner.run(MaClasseTest.class);    }    protected void setUp() throws Exception {          super.setUp();          maClasse = new MaClasse();    }    protected void tearDown() throws Exception {          super.tearDown();          maClasse = null;    }    public void testAdditioner() {          assertTrue(maClasse.additioner(2,2) == 4);  } }
    56. 56. Junit : lancement du test Regrouper les tests : Sur un projet ou un package Faire new JunitTestSuite (Other) Junit4
    57. 57. Tests : Les couches Blabla Objets métier CTRL BD Serialisation <ul><li>Les objets métier offrent des interfaces pour les IHM (le CTRL) </li></ul><ul><li>En analyse : Les trois axes d' une classe </li></ul>String global
    58. 58. Couverture de test
    59. 59. Le Refactoring :Principes (1) <ul><li>Programmer au plus simple </li></ul><ul><li>Faire du refactoring tout le temps (comme le ménage) </li></ul><ul><li>Faire des itérations spéciales </li></ul><ul><li>S’assurer que : </li></ul><ul><ul><li>Les tests existent </li></ul></ul><ul><ul><li>Ils sont OK </li></ul></ul><ul><li>Faire des petites choses </li></ul><ul><ul><li>Renommer </li></ul></ul><ul><ul><li>Découper </li></ul></ul><ul><ul><li>Déplacer </li></ul></ul>
    60. 60. Le Refactoring :Principes (2) <ul><li>Mettre en place des design patterns </li></ul><ul><li>Composer des design patterns </li></ul><ul><li>Accepter  de  &quot; refactorer &quot;  le code des autres </li></ul><ul><li>Remonter des interfaces </li></ul><ul><li>Utiliser des Interfaces ou des classes abstraites </li></ul><ul><li>Utiliser les outils de refactoring (Eclipse) </li></ul>
    61. 61. Le refactoring dans Eclipse (1) <ul><li>Extract Method : Crée une nouvelle méthode encapsulant les éléments sélectionnés, et remplace toutes les références à ces éléments (même ailleurs dans le code), par un appel vers cette méthode. </li></ul><ul><li>Rename : Renomme l'élément sélectionné. </li></ul><ul><li>Move : Déplace l'élément sélectionné, par exemple enlever la classe du paquetage actuel, et la place dans un autre paquetage (voire un nouveau) </li></ul><ul><li>Change Method Signature : Modifie la signature de la méthode en cours, c'est-à-dire ses droits d'accès (public / private / protected / default). Peuvent également être modifiés par cet assistant : le type du résultat, l'ordre, le nom et le type des paramètres et les déclarations d'exceptions. </li></ul><ul><li>Convert Local Variable to Field : Transforme une variable locale, définie dans une méthode, en champ de classe </li></ul>
    62. 62. Le refactoring dans Eclipse (2) <ul><li>Extract Local Variable : De la même manière que Extract Method, cette fonction crée une nouvelle variable assignée à l'expression sélectionnée. </li></ul><ul><li>Inline : C'est la fonction inverse de Extract Local Variable : elle rétablit l'expression assignée à la variable, en lieu et place de la variable, qui disparaît. Particulièrement utile si l'on se rend compte qu'une variable locale n'est utilisée qu'une fois, et que le programme n'est jamais assez optimisé. </li></ul><ul><li>Push Down... Pull Up : Ces deux fonctions marchent dans le même sens, mais avec des directions différentes : elles déplacent la sélection respectivement vers la sous-classe ou la superclasse actuelle </li></ul><ul><li>Use Supertype Where Possible : Remplace les occurrences d'un type par l'un de ses supertypes, non sans avoir identifié auparavant tous les emplacements où ce remplacement est possible. </li></ul>
    63. 63. Le refactoring dans Eclipse (3) <ul><li>Extract Interface : À l'instar des précédentes fonctions de types Extract , celle-ci se charge de prendre les éléments sélectionnes et d'en tirer une classe disposant des méthodes de la classe en cours, et implémente cette interface sur la classe. </li></ul><ul><li>Encapsulate Field : Remplace toutes les références à un champ de classe, par des méthodes get et set pour ce champ. </li></ul><ul><li>Introduce Factory : Crée une nouvelle méthode de type Factory (voir plus loin), en générant pour un constructeur donné la méthode statique appropriée. </li></ul>
    64. 64. Le refactoring dans Eclipse (4) <ul><li>Use Supertype Where Possible : Remplace les occurrences d'un type par l'un de ses supertypes, non sans avoir identifié auparavant tous les emplacements où ce remplacement est possible. . </li></ul>
    65. 65. Refactoring : exercice(1) Vidéo-Club <ul><li>Un film </li></ul><ul><li>une catégorie (enf, norm, nouv) </li></ul><ul><li>un titre </li></ul><ul><li>Une location </li></ul><ul><li>concerne un film </li></ul><ul><li>une durée </li></ul><ul><li>Coût de la location </li></ul><ul><li>norm : 2 + 1.5 par jour au de la </li></ul><ul><li>du deuxième jour </li></ul><ul><li>nouv : 3 par jour </li></ul><ul><li>enf : 1.5 + 1.5 par jour au de la </li></ul><ul><li>du troisième jour </li></ul>Bonus : Chaque location donne un point, si une nouveauté est louée plus qu'un jour, alors un point supplémentaire.
    66. 66. Refactoring : exercice(2) Vidéo-Club
    67. 67. Refactoring : exercice(3) Vidéo-Club
    68. 68. Refactoring : correction Vidéo-Club
    69. 69. Les Design patterns Le GoF Comportement Structure Création
    70. 70. Les Design Patterns <ul><li>Problème: Comment allouer des objets en mémoire ? </li></ul><ul><li>Contexte: un grand nombre d ’objets alloués en mémoire virtuelle. </li></ul><ul><li>Solution: identifier les objets amenés à collaborer fréquemment à un certain moment (réalisation d ’un service), et allouer ces objets dans une même page mémoire. </li></ul><ul><li>Alexander writes: </li></ul><ul><ul><li>Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution. </li></ul></ul>Le choix des Design Patterns et de leur codage est un choix d ’architecture Les outils permettent d ’instancier les Design Patterns et de générer automatiquement le code
    71. 71. Présentation des patrons de conception <ul><li>Le patron de conception est l’expression d’une problématique récurrente d’un domaine et la définition d’une solution générique à ce problème. </li></ul><ul><li>Le concept n’est pas spécifique à l’informatique puisque son domaine d’origine est l’architecture. </li></ul><ul><li>Les patrons de conception introduisent la réutilisation des expériences de conception logicielle </li></ul><ul><li>Les problèmes abordés nous sont souvent familiers et les solutions proposées peuvent paraître s’imposer, mais c’est l’utilisation effective et au quotidien de ces préceptes qui constitue le véritable défit et apporte une véritable plus-value. </li></ul>
    72. 72. Description des patrons de conception <ul><li>Un patron de conception est une description textuelle, éventuellement enrichie de modèles UML, d’un problème de conception et du cœur de sa solution. </li></ul><ul><li>Cette description comporte typiquement les éléments suivants : </li></ul><ul><ul><ul><li>Un nom permettant de l’identifier </li></ul></ul></ul><ul><ul><ul><li>Le problème et son contexte </li></ul></ul></ul><ul><ul><ul><li>Les éléments de solution et leurs relations </li></ul></ul></ul><ul><ul><ul><li>Les bénéfices et conséquences induits </li></ul></ul></ul><ul><li>Le catalogue le plus connu est celui de Erich Gamma qui recense dans son livre quelques 23 modèles de conception orientée objet </li></ul>
    73. 73. Classification des patterns Création Comportement Structure
    74. 74. Les Design patterns de comportement (1) <ul><li>State : un objet réagit selon son humeur </li></ul><ul><li>Stratégie : Faire une chose de différentes manières </li></ul><ul><li>Template Methode : Faire une chose de différentes manières </li></ul><ul><li>(avec une recette de base) </li></ul><ul><li>Observer : certains sont intéresses par ce que je fais, mais pas tout le </li></ul><ul><ul><li>temps </li></ul></ul><ul><li>Visiteur : Rajouter une responsabilité à une classe avec des sous </li></ul><ul><ul><li>traitements identiques </li></ul></ul><ul><li>Memento : sauvegarder un objet </li></ul><ul><li>Iterateur : Balayer une collection </li></ul><ul><li>Chaîne de responsabilité : un élément est attendu par un grand nombre </li></ul><ul><ul><li>d'objets </li></ul></ul>
    75. 75. Les Design patterns de comportement (2) <ul><li>Commande : encapsule une requête dans un objet, et permet les files </li></ul><ul><ul><li>d'attentes, les journalisassions , et retours en arrière (undo). </li></ul></ul><ul><li>Médiateur : définit un objet qui encapsule la manière dont un </li></ul><ul><ul><li>ensemble d'objets interagissent. </li></ul></ul><ul><li>Interpréteur : définit un langage ainsi que sa grammaire, et fournit un </li></ul><ul><ul><li>interpréteur pour utiliser la représentation du langage. </li></ul></ul>
    76. 76. l ’Automate : contexte <ul><li>Problème : Un même objet doit répondre à une même sollicitation de plusieurs manières différentes suivant son état interne. Les opérations produisent des résultats qui dépendent de l’état interne. </li></ul><ul><li>Contexte : Fournir un approche systématique d ’implantation des diagrammes d ’états UML </li></ul><ul><li>Solution : On va dissocier l’état de l’objet de l’objet lui-même. Les états seront matérialisés par autant de classes, chacune spécialisée dans la gestion d’un de ces états. L’objet n’a plus qu’à gérer une instance représentant l’état courant et délègue les appels de méthodes à cette instance. Une classe parente abstraite ou une interface commune permettra à l’objet de les manipuler d’une façon homogène. </li></ul>
    77. 77. State : Préambule <ul><li>Soit des stagiaires qui réagissent selon leur humeur : </li></ul><ul><li>Si on leur demande de travailler: </li></ul><ul><ul><li>Si c’est le matin, ils écoutent. </li></ul></ul><ul><ul><li>Si c’est l’après midi, ils font la sieste. </li></ul></ul><ul><ul><li>Si c’est midi juste, ils grognent…… </li></ul></ul><ul><li>Si on leur demande de faire un exercice ………. </li></ul>
    78. 78. State : UML Client Etat +Op1(Context) +Op2(Context) +Op3(Context) * Etat1 +Op1(Context) +Op2(Context) Etat2 +Op2(Context) +Op3(Context)
    79. 79. State : Participants <ul><li>Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Context   </li></ul></ul><ul><ul><ul><li>Défint la classe principale utilisée par le client </li></ul></ul></ul><ul><ul><ul><li>Garde une instance de la sous classe state pour définir l’état courant. </li></ul></ul></ul><ul><ul><li>Etat  </li></ul></ul><ul><ul><ul><li>Définit l’interface des différents états. </li></ul></ul></ul><ul><ul><li>Concrete State </li></ul></ul><ul><ul><ul><li>Chaque sous classe implémente l’interface du State conformément à ce qui est faisable dans cet état. </li></ul></ul></ul>
    80. 80. State : Exercice1- La banque SilverState(0-1000) do: Interet = 10% RedState(<0) do: Interet = 0 do: Frais = 15 GoldenState(>1000) do: Interet = 50% [ balance > 1000 ] [ balance < 0 ] [ balance > 0 ] [ balance < 1000 ] [ balance < 0 ] la banque
    81. 81. State : Exercice1- La banque balance<0 => Interet 0% Balance entre 0 et 1000 => Interet 10% Balance > 1000 => Interet 50% balance<0 => Pénalité de 15 la banque
    82. 82. State : Exercice1 int main() { Account account(&quot;Jim&quot;); account.Deposit(500.0); account.PayInterest (); account.Deposit(300.0); account.PayInterest (); account.Deposit(550.0); account.PayInterest(); account.Withdraw(2000.00); account.PayInterest(); account.Withdraw(1100.00) ; account.Withdraw(1000); account.PayInterest(); account.Deposit(2000); return 0; } Gold Silver r Silver Red Silver la banque
    83. 83. State + Singleton
    84. 84. State + Singleton Exo2 Objet o; o.C1();o.C2();o.C3();o.C3(); Objet o1; o1.C1();o1.C3();o1.C2(); o1.C1();o1.C2();o1.C3(); o1.C1();o1.C3(); Automate
    85. 85. State : Remarques <ul><li>Remarques : </li></ul><ul><ul><li>Les états concrets peuvent posséder une référence à l’objet (possibilité pour l ’état concret de manipuler les attributs de l ’objet) </li></ul></ul><ul><ul><li>Le changement d’état peut être gérer par l’objet lui-même ou par les états concrets. </li></ul></ul><ul><li>Conséquences : </li></ul><ul><ul><li>De nouveaux états peuvent être facilement ajoutés </li></ul></ul><ul><ul><li>Les transitions d’état sont plus explicites </li></ul></ul><ul><ul><li>Si les états concrets n’ont pas d’états internes (variables), alors ils peuvent être partagés (singleton) </li></ul></ul>Plus simple
    86. 86. Stratégie : contexte <ul><li>On utilise Stratégie lorsque : </li></ul><ul><li>De nombreuses classes associées ne diffèrent que par leur comportement. </li></ul><ul><li>Ce pattern permet de configurer une classe avec un comportement parmi </li></ul><ul><ul><li>plusieurs. </li></ul></ul><ul><li>On a besoin de plusieurs variantes d'algorithme. </li></ul><ul><li>Un algorithme utilise des données que les clients ne doivent pas </li></ul><ul><ul><li>connaître. </li></ul></ul>
    87. 87. Stratègie : UML
    88. 88. Stratègie : Participants <ul><li>     Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Strategie  (SortStrategy) </li></ul></ul><ul><ul><ul><li>Déclare une interface commune pour tous les algorithmes supportés. </li></ul></ul></ul><ul><ul><li>ConcreteStrategie  (QuickSort, ShellSort, MergeSort) </li></ul></ul><ul><ul><ul><li>Implémente un algorithme conformément à l’interface de la Strategie. </li></ul></ul></ul><ul><ul><li>Context  (SortedList) </li></ul></ul><ul><ul><ul><li>Est configuré avec un objet concreteStrategy </li></ul></ul></ul><ul><ul><ul><li>Maintient une référence sur un objet Strategy </li></ul></ul></ul><ul><ul><ul><li>Peut définir une interface qui permet à la stratégie d’accéder ses données. </li></ul></ul></ul>
    89. 89. Stratègie : Exo <ul><li>Renvoyer </li></ul><ul><li>Celui qui gagne le plus </li></ul><ul><li>Celui qui prend le plus de vacances </li></ul><ul><li>Celui qui …… </li></ul>public static void main(String[] args) { Entreprise e= new Entreprise(); Employe trouve; e.Ajouter(new Employe (&quot;Tchutchu&quot; , 999999 , 0)); e.Ajouter(new Employe (&quot;Duchmoll&quot; , 1000 , 10)); e.Ajouter(new Employe (&quot;Casta&quot; , 10000 , 30)); e.setMaStrategie(new RechercherGrossesVacances()); trouve = e.Rechercher(); System.out.println (&quot;Virer le paresseux : &quot; + trouve.getNom()); e.setMaStrategie(new RechercherGrosSalaire()); trouve = e.Rechercher(); System.out.println (&quot;Virer le plus cher : &quot; + trouve.getNom()); } Virer le paresseux : Casta Virer le plus cher : Tchutchu
    90. 90. Patron de méthode : principe <ul><li>C’est du code (un algorithme cablé pour toutes les sous classes) </li></ul><ul><ul><li>qui est fait principalement par appel de méthodes virtuelles </li></ul></ul><ul><ul><li>et abstraites . </li></ul></ul><ul><li>Ressemble à un template C++ </li></ul><ul><ul><li>Mécanismes très différents </li></ul></ul><ul><ul><li>Plus souple </li></ul></ul><ul><ul><ul><li>Les traitements peuvent diverger d’une sous classe à l’autre </li></ul></ul></ul><ul><ul><ul><ul><li>alors que cela est impossible avec les templates </li></ul></ul></ul></ul><ul><ul><li>Plus simple </li></ul></ul><ul><li>C’est du code en avance sur les futures sous-classes </li></ul><ul><li>Avantage : Découpe des méthodes en méthodes plus fines </li></ul>
    91. 91. Patron de méthode : Exemple TravaillerMatin(); Dejeuner(); TravaillerApresMidi(); Loisir(); Dormir(); Patron de méthode vivre If (age > 15) TravaillerMatin(); else Jouer(); ………… . MiamMiam RonRon C’est drôle
    92. 92. Patron de méthode BlaBlater: BlaBla TravaillerMatin: BlaBlater(); TravaillerApresMidi: BlaBlater(); Loisir: BlaBlater Personneb age : int Dejeuner() <<{abstract}>> TravaillerMatin() <<{abstract}>> TravaillerApresMidi() <<{abstract}>> Loisir() Dormir() Jouer() <<abstract>> Vivre() Chirurgien TravaillerMatin() TravaillerApresMidi() Loisir() Professeur TravaillerMatin() TravaillerApresMidi() Loisir() BlaBlater() TravaillerMatin: Ouvrir(); TravaillerApresMidi: Fermer(); Loisir: Histoire grivoise
    93. 93. Patron de méthode TravaillerMatin(); Dejeuner(); TravaillerApresMidi(); Loisir(); Dormir(); TravaillerMatin: Dormir(); TravaillerApresMidi: AllerANPE(); Loisir: Pleurer();
    94. 94. Patron de méthode : Exo : Impôts <ul><li>Nouvelle loi de finance : </li></ul><ul><li>Impôts sur le revenu : </li></ul><ul><ul><ul><li>Couple avec enfants : Frais : -20 % moins 1000 par enfant IR = reste * 2/12 </li></ul></ul></ul><ul><ul><ul><li>Couple sans enfant : Frais : -20 % IR = reste * 3/12 </li></ul></ul></ul><ul><ul><ul><li>Célibataire Frais : -10 % IR = reste * 4/12 </li></ul></ul></ul><ul><li>Taxe d’habitation </li></ul><ul><ul><ul><li>Couple avec enfants : Un loyer moins 50 par enfants </li></ul></ul></ul><ul><ul><ul><li>Couple sans enfant : Deux loyers </li></ul></ul></ul><ul><ul><ul><li>Célibataire Deux loyers + 1000 </li></ul></ul></ul><ul><li>ISF </li></ul><ul><ul><ul><li>Couple avec enfants : 20% de (ISF-300000) si > 300000 sinon 0 </li></ul></ul></ul><ul><ul><ul><li>Couple sans enfant : 20% de (ISF-200000) si > 200000 sinon 0 </li></ul></ul></ul><ul><ul><ul><li>Célibataire 20% de (ISF-80000) si > 100000 sinon 0 </li></ul></ul></ul><ul><li>Tout le monde profite d’un parachute (non golden) qui s’élève au max à 50% des revenus. </li></ul><ul><li>Un célibataire libéral paye un surplus d’impôt de 5000 indépendamment du parachute fiscal </li></ul><ul><li>TVA sociale augmente de 5 points </li></ul>(Calcul sur le revenu annuel) Déclaration : Revenu annuel-loyer mensuel-fortune-nombre d’enfants
    95. 95. Patron de méthode : Exo : Impôts
    96. 96. l’Observer : le contexte <ul><li>Problème : Définir une interdépendance de type (de classe) un à plusieurs, de façon telle que, quand un objet change d'état, tous ceux qui en dépendent en soit notifiés pour assumer leur propre mise à jour. </li></ul><ul><li>Contexte : Ne pas présumer de l’identité des objets intéressés par l’événement (limitation du couplage). Ne pas présumer du nombre des intéressés </li></ul><ul><li>Solution : Implantation d’une interaction entre objets de type souscription-diffusion </li></ul>
    97. 97. l’Observer : la solution <ul><li>le Sujet : Définit un mécanisme général de gestion des objets en dépendance </li></ul><ul><ul><ul><li>Maintient la liste des Observeurs à l ’aide des méthodes attach(Observer*) et detach(Observer *) </li></ul></ul></ul><ul><ul><ul><li>Fournit le mécanisme permettant de prévenir les Observeurs lorsqu ’un changement d ’état se produit </li></ul></ul></ul><ul><li>l ’Observeur : Définit l ’interface update() permettant d ’être prévenu d ’un changement d ’état </li></ul><ul><li>le SujetConcret : Sous-classe de Sujet, gère son état interne et invoque notify() lorsque son état change </li></ul><ul><li>les Observeurs Concrets : Sous-Classes d ’Observeur, implentent l ’interface update() en fonction de leur besoin </li></ul>
    98. 98. l’Observer : UML Réutilisable Rmq : souvent UpDate contient des paramètres (evt, le sujet, l'état du sujet, …)
    99. 99. l ’Observer : la dynamique
    100. 100. Observer : Participants <ul><li>  Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Sujet    (Stock) </li></ul></ul><ul><ul><ul><li>Conna î t les observateurs. Plusieurs observateurs peuvent observer un même sujet. Cela peut être dynamique. </li></ul></ul></ul><ul><ul><ul><li>Offre un moyen d ’ attacher et de d é tacher les observateurs. </li></ul></ul></ul><ul><ul><li>SujetConcret   (IBM) </li></ul></ul><ul><ul><ul><li>C ’ est lui qui contient l ’ information observable. </li></ul></ul></ul><ul><ul><ul><li>Pr é vient les observateurs quand l ’ information change. </li></ul></ul></ul><ul><ul><li>Observer    (IInvestor) </li></ul></ul><ul><ul><ul><li>C ’ est juste la d é finition de l ’ interface. </li></ul></ul></ul><ul><ul><li>les Observeri    (Investor) </li></ul></ul><ul><ul><ul><li>Garde une r é f é rence sur le Sujet concret </li></ul></ul></ul><ul><ul><ul><li>impl é mente l ’ interface de l ’ observer pour aller chercher l ’ information. </li></ul></ul></ul>
    101. 101. Observer : Java setChanged () {changed = true;} NotifyObservers() { if (changed) { for each observer update(); changed = false; } Cela permet d'optimiser en n'appelant pas les observers à chaque changement d'état du sujet,mais seulement après un setChanged(). import java.util.*;
    102. 102. Observer : Java- Swing Public class Exemple{ JFrame cadre; Public static main(){ Exemple e = new Exemple(); e.go();} Public void go(){ cadre =new JFrame(); Jbutton b = new Jbutton (« Dois-je le faire »); b.AddActionListener(new Ange()); b.AddActionListener(new Demon()); ………………………………… .} } class Ange implements ActionListener { Public void ActionPerformed(ActionEvent e) {Print « Non »}} class Ange implements ActionListener { Public void ActionPerformed(ActionEvent e) {Print « Oui »}} Dois-je le faire Non Oui
    103. 103. Observer : Exercice1 Mer-Montagne Meteo.Calculer met température entre 0 et 20. Skieur.update va en vacances si la température est < 10° Nageur.update va en vacances si la température est >= 10° Meteo m = new Meteo(); Nageur n = new Nageur(); Skieur s =new Skieur(); m.addObserver(n); m.addObserver(s); m.calculer(); m.setChanged(); m.calculer(); m.setChanged(); m.calculer(); m.setChanged(); m.calculer(); le skieur va a la montagne : 8 le nageur va a la mer : 12 le skieur va a la montagne : 6 8 8 12 ? Observable -changed: bool +addObserver(Observer) +deleteObserver(Observer) +countObservers(): int +deleteObservers() +notifyObservers() #setChanged() Observer Meteo -temperature: int +setChanged() +calculer() +getTemperature(): int Skieur +update(p1: Observable, p2: Object) Nageur +update(p1: Observable, p2: Object) Main +main(args: String)
    104. 104. Observer : Exercice2 Les villes
    105. 105. Visitor <ul><li>Rajouter une (ou plusieurs) méthode à un objet </li></ul><ul><li>(sans la rajouter) !!!! </li></ul><ul><li>A utiliser quand une classe ne sait pas ce qu’elle veut et </li></ul><ul><li>qu’elle risque de vouloir beaucoup de choses. </li></ul><ul><li>La classe fait déjà beaucoup de petites choses </li></ul><ul><li>L'objet visité accepte le visiteur (Accept (Visitor v)) </li></ul><ul><li>Il dit alors à v de visiter (v.Visit()) </li></ul><ul><li>v fait son travail </li></ul>
    106. 106. Visitor : UML
    107. 107. Visiteur et l’objet Composite Iterator iter =employees.iterator(); { Employee e; while (iter.hasNext()) { e =(Employee)iter.next(); e.Accept(visitor);} } RMQ : Il est possible d’explorer l’ensemble d’un composite avec un visiteur. Dans ce cas Employee et Employees ont tous les deux une méthode Accept et sont donc des Elements.
    108. 108. Visitor :exercice Salaire Vacances public static void main(String[] args) { Employees e = new Employees(); e.Attach(new Clerk(&quot;Hank&quot;, 25000.0, 14)); e.Attach(new Director(&quot;Elly&quot;, 35000.0, 16)); e.Attach(new President(&quot;Sarko&quot;, 45000.0, 21)); e.Accept(new IncomeVisitor()); e.Accept(new VacationVisitor()); } <ul><li>Une entreprise veut soit : </li></ul><ul><li>augmenter les salaires de 10% </li></ul><ul><li>donner 2 jours de vacances supplémentaires </li></ul><ul><li>d'autres combinaisons TBD </li></ul>
    109. 109. Visitor :correction Salaire Vacances
    110. 110. Mémento : UML La classe à surveiller-----La mémoire----Le programme client (main) UnDo-ReDo
    111. 111. Mémento : Participants <ul><ul><li>Memento  </li></ul></ul><ul><ul><ul><li>Stock l’état interne (tout ou partie) de l’objet Origine. </li></ul></ul></ul><ul><ul><ul><li>Il se protège contre les accès provenant d’autres objets que l’Originator. Les mementos ont en effet 2 interfaces. Le careTaker voit une interface simplifiée, il peut seulement passer le memento à d’autres objets. Au contraire l’originator voit une large interface, qui lui permet d’accéder a tous les champs. </li></ul></ul></ul><ul><ul><li>Originator  </li></ul></ul><ul><ul><ul><li>Crée un memento contenant une photo de lui même à un instant donné (sauvegarde). </li></ul></ul></ul><ul><ul><ul><li>Utilise le memento en cas de restauration. </li></ul></ul></ul><ul><ul><li>Caretaker  </li></ul></ul><ul><ul><ul><li>Est responsable de la gestion des sauvegardes-restauration </li></ul></ul></ul><ul><ul><ul><li>Il ne regarde jamais le contenu interne du Memento </li></ul></ul></ul>
    112. 112. Mémento : Exemple(1) import java.util.*; // &quot;Originator&quot; class SalesProspect { private String name; private String phone; private double budget; public String getName() { return name; } public void setName(String value) { name = value; } public String getPhone() { return phone; } public void setPhone (String value) { phone = value; } public double getBudget() { return budget; } public void setBudget (double value) { budget = value; } public Memento SaveMemento() {return (new Memento( name, phone, budget ));} public void RestoreMemento( Memento memento ) { this.name = memento.getName(); this.phone = memento.getPhone(); this.budget = memento.getBudget(); } public void Afficher() { System.out.println( &quot;Sales prospect ---- &quot; ); System.out.println( &quot;Name: &quot; + this.name ); System.out.println( &quot;Phone: &quot; + this.phone ); System.out.println( &quot;Budget:&quot; + this.budget ); } } class Memento { private String name; private String phone; private double budget; // Constructors public Memento( String name, String phone, double budget ) { this.name = name; this.phone = phone; this.budget = budget; } public String getName() { return name; } public void setName(String value) { name = value; } public String getPhone() { return phone; } public void setPhone (String value) { phone = value; } public double getBudget() { return budget; } public void setBudget (double value) { budget = value; } } // &quot;Caretaker&quot; class ProspectMemory { private Memento memento; public void setMemento (Memento value){ memento = value; } public Memento getMemento () { return memento; } }
    113. 113. Mémento : Exemple(2) public class MementoApp { public static void main(String argv[]) { SalesProspect s = new SalesProspect(); s.setName ( &quot;Landru&quot;); s.setPhone (&quot;08080808&quot;); s.setBudget( 25000.0); s.Afficher(); // Store internal state ProspectMemory m = new ProspectMemory(); m.setMemento( s.SaveMemento()); // Continue changing originator s.setName( &quot;Tintin&quot;); s.setPhone( &quot;33333333&quot;); s.setBudget( 1.0); s.Afficher(); // Restore saved state s.RestoreMemento( m.getMemento() ); s.Afficher(); } }
    114. 114. Memento : UML-Dynamique : Client : Caretaker : Originator : Memento <<create>> SaveMemento(): void <<create>> SetState(): void rend le memento SetMemento(p Memento): void GetMemento(): void RestoreMemento(m): void GetState(): void mis a jour de l' é tat()
    115. 115. L’Itérateur-Iterator : le contexte <ul><li>Balayer des collections </li></ul><ul><li>Problème, pas d'iterateur pour les tableaux, mais on peut </li></ul><ul><ul><li>le développer </li></ul></ul>
    116. 116. Itérateur: UML
    117. 117. Iterateur : Participants <ul><li>Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Iterator   </li></ul></ul><ul><ul><ul><li>définit une interface pour accéder et traverser les éléments d’une collection. </li></ul></ul></ul><ul><ul><li>ConcreteIterator  (Iterator) </li></ul></ul><ul><ul><ul><li>implémente l’interface Iterator. </li></ul></ul></ul><ul><ul><ul><li>garde trace de la position courante dans la collection. </li></ul></ul></ul><ul><ul><li>Aggregate  (AbstractCollection) </li></ul></ul><ul><ul><ul><li>définit une interface pour créer (obtenir) un objet Iterator. </li></ul></ul></ul><ul><ul><li>ConcreteAggregate  (Collection) </li></ul></ul><ul><ul><ul><li>Implémente l’interface de création et rend une instance d’un objet ConcreteIterator </li></ul></ul></ul>
    118. 118. Itérateur : remarques <ul><li>Un itérateur est dit robuste, s’il garantit que insertions et suppressions n’interféreront pas avec le parcours. </li></ul><ul><li>Problème Multithread </li></ul><ul><li>Des opérations supplémentaires peuvent être utilisées : SauteA, Précédent… </li></ul><ul><li>Une classe ne doit avoir qu'une seule responsabilité (au sens large) </li></ul><ul><li>sinon, il y a plus </li></ul><ul><li>de risques de </li></ul><ul><li>changement </li></ul><ul><li>Java 5 (generics) </li></ul><ul><ul><li>For (Object o : Collection) </li></ul></ul><ul><ul><li>{ o.fqq();} </li></ul></ul>
    119. 119. Itérateur & Composite <ul><li>Itérateur interne </li></ul><ul><ul><li>On peut balayer un composite en utilisant l'opération prévue </li></ul></ul><ul><ul><li>(exempleGetCout()). </li></ul></ul><ul><ul><li>Partir de la racine et simplement </li></ul></ul><ul><ul><li>appeler la méthode </li></ul></ul><ul><li>Itérateur externe </li></ul><ul><ul><li>Il faut l'écrire </li></ul></ul><ul><ul><li>Mise en œuvre d'une pile </li></ul></ul><ul><ul><li>Utiliser des iterator normaux pour les </li></ul></ul><ul><ul><li>éléments composés </li></ul></ul>
    120. 120. Itérateur : Exercice <ul><li>Reprendre l'ordinateur du Composite </li></ul><ul><li>Mettre les différents éléments dans des tableaux </li></ul><ul><li>Faire un iterateur de tableau </li></ul><ul><li>Faire un itérateur externe pour l'ensemble </li></ul>le prix d'un ordi
    121. 121. Chaîne de Responsabilité <ul><li>Polymorphisme et récursivité </li></ul><ul><li>Utiliser la pattern Chaîne de responsabilité quand vous voulez donner à plus d’un objet une </li></ul><ul><ul><li>chance de traiter une requête </li></ul></ul><ul><li>L’ensemble des objets est construit dynamiquement </li></ul><ul><li>Avantages : </li></ul><ul><ul><li>Découple l’émetteur de la requête de ses récepteurs </li></ul></ul><ul><ul><li>Simplifie l’objet qui envoie la requête car, il n’a pas besoin de connaître la structure de </li></ul></ul><ul><ul><ul><li>la hiérarchie utilisée, ni de conserver des références directes sur les membres. </li></ul></ul></ul><ul><ul><li>Permet d’ajouter, modifier , supprimer des responsabilités en changeant la hiérarchie </li></ul></ul><ul><li>Exemples : </li></ul><ul><ul><li>Machine à trier les pièces </li></ul></ul><ul><ul><li>Traitement des mails </li></ul></ul><ul><ul><ul><li>lettres de fan => PDG </li></ul></ul></ul><ul><ul><ul><li>réclamations => Service juridique </li></ul></ul></ul><ul><ul><ul><li>demandes de modification => R&D </li></ul></ul></ul><ul><ul><ul><li>publicité => Poubelle </li></ul></ul></ul>
    122. 122. Chain of Resp : UML <ul><li>Deux temps : </li></ul><ul><li>Configurer la hiérarchie </li></ul><ul><li>Faire des demandes </li></ul>
    123. 123. Chain of Resp : Participants <ul><li>  Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Handler   (Approver) </li></ul></ul><ul><ul><ul><li>définit une interface pour gérer les requêtes </li></ul></ul></ul><ul><ul><ul><li>(optionnel) implémente le lien successeur </li></ul></ul></ul><ul><ul><li>ConcreteHandler   (Director, VicePresident, President) </li></ul></ul><ul><ul><ul><li>Gère une requête si il en est responsable </li></ul></ul></ul><ul><ul><ul><li>Peut accéder à son successeur </li></ul></ul></ul><ul><ul><ul><li>Passe la requête à son successeur si il ne peut pas la traiter </li></ul></ul></ul><ul><ul><li>Client   (ChainApp) </li></ul></ul><ul><ul><ul><li>Provoque le premier appel de la requête vers un ConcreteHandler de la chaîne des successeurs. </li></ul></ul></ul>
    124. 124. Chain of Resp : Exo Président <100000 Vice-président <25000 Directeur <10000 Comité >=100000 Director grouillot = new Director(); VicePresident Sam = new VicePresident(); President Tammy = new President(); Grouillot.SetSuccessor(Sam); Sam.SetSuccessor(Tammy); Purchase p = new Purchase( 350.00, &quot;Formation&quot;); Grouillot.ProcessRequest(p); p = new Purchase( 24000, &quot;Voiture&quot;); Grouillot.ProcessRequest(p); p =new Purchase ( 99000, &quot;Maison&quot;); Grouillot.ProcessRequest(p); p = new Purchase( 122100.00, &quot;Usine&quot;); Grouillot.ProcessRequest(p); U M V F
    125. 125. Command <ul><li>Faire faire qq chose à un objet sans le connaître </li></ul><ul><li>Commander qq chose sans connaître celui qui le fera </li></ul><ul><li>Réduction du couplage </li></ul><ul><li>Permet : </li></ul><ul><ul><li>les logs (historiques) </li></ul></ul><ul><ul><li>les undo-redo (avec ou sans Memento) </li></ul></ul><ul><ul><li>temporisation d'action </li></ul></ul><ul><ul><li>mise en file d'attente </li></ul></ul><ul><ul><li>contrôle </li></ul></ul><ul><ul><li>souvent utiliser avec un composite pour exécuter plusieurs </li></ul></ul><ul><ul><ul><li>commandes (notion de macro commande) </li></ul></ul></ul>
    126. 126. Command : UML Configurateur Utilisateur
    127. 127. Command : Participants <ul><li>  Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Command </li></ul></ul><ul><ul><ul><li>définit une interface pour faire faire qq chose (Execute) </li></ul></ul></ul><ul><ul><li>ConcreteCommand </li></ul></ul><ul><ul><ul><li>Connaît celui qui fait qq chose (Receiver) </li></ul></ul></ul><ul><ul><ul><li>Implémente la méthode Execute en faisant faire le travail au </li></ul></ul></ul><ul><ul><ul><ul><li>receiver. </li></ul></ul></ul></ul><ul><ul><li>Receiver </li></ul></ul><ul><ul><ul><li>Fait le travail, il ne connaît personne </li></ul></ul></ul><ul><ul><li>Client    </li></ul></ul><ul><ul><ul><li>Connaît la ou les commandes concrètes et les initialisent avec un receiver. </li></ul></ul></ul><ul><ul><li>Invoker </li></ul></ul><ul><ul><ul><li>Fait faire qq chose sans connaître ni les commandes concrètes ni les receivers (seulement l'interface) </li></ul></ul></ul>
    128. 128. Command : Exo Architecture <ul><li>Un architecte (client) </li></ul><ul><li>Chef de chantier (Invoker) </li></ul><ul><li>Plâtrier (Receiver) </li></ul><ul><li>Maçon (Receiver) </li></ul><ul><li>Couvreur (Receiver) </li></ul><ul><li>Couvreur véreux (Receiver) </li></ul><ul><li>Faire les murs externes (Action) </li></ul><ul><li>Faire les murs internes (Action) </li></ul><ul><li>Faire le toit (Action) </li></ul><ul><li>Faire des recettes (DeAction) </li></ul><ul><li>Construire (Command) </li></ul>Je construis les murs ext Je construis le toit Je casse le toit Je construis le toit Je casse le toit Je construis le toit Je construis les murs int
    129. 129. Command : Correction Architecture Je construis les murs Je construis le toit Je casse le toit Je construis le toit Je casse le toit Je construis le toit Je construis les murs
    130. 130. Interpreter : UML
    131. 131. Mediator : UML Mediator ConcreteMediator Colleague +mediator bouton liste textArea Controleur menu Rmq :Façade-Observer
    132. 132. Les Design patterns Le GoF Structure <ul><li>Proxy : cacher la complexité d'un objet </li></ul><ul><li>Décorateur : Rajouter une responsabilité à une classe sans changer l'interface </li></ul><ul><li>Adaptateur : Adapter un objet à un autre </li></ul><ul><li>Composite : permet de traiter une structure d'objets de manière uniforme </li></ul><ul><ul><li>(Des feuilles et des nœuds) </li></ul></ul><ul><li>Façade : Représenter, regrouper et diriger un ensemble d'objets </li></ul><ul><li>Poids mouche : Partager de nombreux minis objets </li></ul><ul><li>Pont : permet de différencier une abstraction de son implémentation, </li></ul><ul><ul><li>permettant à chacune d'évoluer indépendamment. </li></ul></ul>
    133. 133. Proxy :le contexte <ul><li>On utilise un proxy : </li></ul><ul><li>pour référencer un objet par un moyen plus complexe qu'un &quot;pointeur&quot;. </li></ul><ul><li>pour rajouter, modifier, supprimer des responsabilités à un objet sans en </li></ul><ul><ul><li>changer ni la structure interne, ni l'interface. </li></ul></ul><ul><li>Il existe plusieurs types de proxy : </li></ul><ul><li>Proxy distant (RMI) </li></ul><ul><li>Proxy virtuel pour le cas de chargement d'objet très volumineux </li></ul><ul><li>Proxy de protection </li></ul><ul><li>Proxy de référence intelligente : </li></ul><ul><ul><li>Persistence </li></ul></ul><ul><ul><li>Comptage de référence </li></ul></ul><ul><li>……… . </li></ul>
    134. 134. Proxy : UML Proxy.Operation1() { fait qqchose….. leSujet.Operation1();} Proxy.Proxy(Sujet param){ leSujet = param;}
    135. 135. Proxy : Participants <ul><li>  Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Proxy   </li></ul></ul><ul><ul><ul><li>remplace l ’ objet r é el et pointe vers celui-ci </li></ul></ul></ul><ul><ul><ul><li>Operation1 fait le traitement suivant: </li></ul></ul></ul><ul><ul><ul><ul><li>Proxy distant : fabrique un message et l'envoie au Sujet r é el via </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>un skeleton. Le proxy s'appelle alors un stub. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Proxy de protection : v é rifie si l'appelant a les droits pour ex é cuter </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>l'op é ration, il l'accepte ou la refuse. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>On peut utiliser l'API InvocationHandler </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Proxy virtuel : exemple chargement d'une image. Le proxy lance </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>le chargement de l'image et affiche le % de temps restant. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Lorsque l'image est charg é e, alors il l'affiche. </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Proxy de r é f é rence intelligente : exemple smart pointer du C++ </li></ul></ul></ul></ul><ul><ul><li>Sujet    </li></ul></ul><ul><ul><ul><li>D é finit l ’ interface commune au proxy et au sujet r é el. </li></ul></ul></ul><ul><ul><li>SujetReel </li></ul></ul><ul><ul><ul><li>D é finit l ’ objet r é el que le proxy repr é sente . </li></ul></ul></ul>
    136. 136. Proxy Distant RPC RMI CORBA DCOM WEBSERVICE Stub skeleton IDL Interface WSDL SujetReel +Operation1() Proxy +Operation1() +Proxy(p: Sujet) Sujet +Operation1() Client Call Send Call RMIC
    137. 137. Proxy Distant :RMI (1) <ul><li>Utilisation de rmi ( import java.rmi.* ) </li></ul><ul><li>Créer une interface distante: </li></ul><ul><ul><li>public interface Sujet extends Remote </li></ul></ul><ul><ul><li>public void Operation1 () throws RemoteException ; </li></ul></ul><ul><ul><li>s'assurer que les paramètres et valeur de retour sont serialisable </li></ul></ul><ul><li>Créer une implémentation distante SujetReel </li></ul><ul><ul><li>public class SujetReel extends UnicastRemoteObject implements Sujet </li></ul></ul><ul><ul><li>Ecrire un constructeur sans argument,avec excpt </li></ul></ul><ul><ul><ul><li>public SujetReel () throws RemoteException vv </li></ul></ul></ul><ul><ul><li>Enregistrer le service </li></ul></ul><ul><ul><ul><li>try { </li></ul></ul></ul><ul><ul><ul><li>SujetReel leSujetReel = new SujetReel (); </li></ul></ul></ul><ul><ul><ul><li>naming . rebind ( &quot; BonjourDeLoin &quot; , leSujetReel ); </li></ul></ul></ul><ul><ul><ul><li>} catch ( Exception e) {…} </li></ul></ul></ul>
    138. 138. Proxy Distant :RMI (2) <ul><li>Générer le stub (proxy) et le skeleton </li></ul><ul><ul><li>lancer rmic sur le fichier SujetReel.java </li></ul></ul><ul><ul><li>rmic SujetReel </li></ul></ul><ul><li>Exécuter rmiregistry (outil pour l'enregistrement) </li></ul><ul><ul><li>en tapant simplement dans une fenêtre dos rmiregistry </li></ul></ul><ul><li>Démarrer le service en tapant : java SujetReel </li></ul><ul><li>Le client peut alors utiliser le service </li></ul><ul><ul><li>Sujet monSujet = (Sujet) Naming . Lookup </li></ul></ul><ul><ul><li>(&quot;rmi://127.0.0.1/ BonjourDeLoin&quot;); </li></ul></ul><ul><ul><li>monSujeT.Operation1(); </li></ul></ul>Proxy Distant :Exercice Bonjour de loin
    139. 139. Proxy de protection :exercice (1) le patron et les grouillots
    140. 140. Proxy de protection :exercice (2) le patron et les grouillots
    141. 141. Proxy de protection avec InvocationHandler Moi même Les autres getNom() getSexe() getInterest() getSexyOuNon() SetNom(String) setSexe(String) setInterest(String) setSexyOuNon(int) Rmq : setSexyOuNon () fait la moyenne des notes obtenues getNom() getSexe() getInterest() getSexyOuNon() SetNom(String) setSexe(String) setInterest(String) setSexyOuNon(int) BeanPersonne <<interface>> ~getNom(): String ~getSexe(): String ~getInterets(): String ~getSexyOuNon(): int ~setNom(nom: String) ~setSexe(sexe: String) ~setInterets(interets: String) ~setSexyOuNon(note: int)
    142. 142. Proxy de protection avec InvocationHandler
    143. 143. Méthode invoke de non Propriétaire InvocationHandlerNonProprietaire public Object invoke(Object proxy, Method method, Object[] args) throws IllegalAccessException { try { if (method.getName().startsWith(&quot;get&quot;)) { return method.invoke(personne, args); } else if (method.getName().equals(&quot;setSexyOuNon&quot;)) { return method.invoke(personne, args);} else if (method.getName().startsWith(&quot;set&quot;)) { throw new IllegalAccessException(); } } catch (InvocationTargetException e) { e.printStackTrace();} return null; }
    144. 144. Méthode invoke de Propriétaire InvocationHandlerProprietaire public Object invoke(Object proxy, Method method, Object[] args) throws IllegalAccessException { try { if (method.getName().startsWith(&quot;get&quot;)) { return method.invoke(personne, args); } else if (method.getName().equals(&quot;setSexyOuNon&quot;)) { throw new IllegalAccessException();} else if (method.getName().startsWith(&quot;set&quot;)) { return method.invoke(personne, args);} } catch (InvocationTargetException e) {e.printStackTrace();} return null; }
    145. 145. Proxy invocationHandler :Exercice(1) le club de rencontres Rmq basedonnees est une Hashtable ---------------------------------------------- Passage difficile :
    146. 146. Proxy invocationHandler :Exercice(2) le club de rencontres
    147. 147. Decorator : Présentation Problème : nombreux héritages Solution : Héritage  héritage + agrégation (poupée russe)
    148. 148. Decorator :Le problème(1) Nous allons revoir la façon dont on abuse généralement de l’héritage et vous allez apprendre comment « décorer » vos classes au moment de l’exécution en utilisant une forme de composition. Pourquoi? Une fois que vous connaîtrez les techniques de décoration, vous pourrez affecter à vos objets (ou à ceux des autres) de nouvelles responsabilités sans modifier le code des classes sous-jacentes. RMQ :Le principe d’Ouverture (n’hésitez pas à étendre nos classes) et de Fermeture (Pas touche à mon code) Un Deca avec du lait et du citron
    149. 149. Decorator :Le problème(2) Ecrire les méthodes Boisson::Cout et Colombia::Cout Boisson.Cout() { If GetLait() then cout += coutDuLait If GetVanille() then cout += coutVanille ………………………………………… . Return cout; } Colombia::Cout () { Return 25+ super.Cout() } Que se passe-t-il si on rajoute la crème Chantilly? Il faut modifier Boisson.Cout --- Pas touche à mon code
    150. 150. Decorator : UML Decorateuri.Operation(): fait qq chose super.Operation() Cela revient à rajouter une responsabilité à une classe mais sans en changer l'interface. Comparer avec le composite ComposantConcret.Operation : fin de la chaîne Decorateur.Operation() : monComposant.Operation()
    151. 151. Decorator : la solution construction Deca Lait Citron La boisson Les ingrédients <ul><li>Fabrication de l'objet : </li></ul><ul><li>Boisson b= new Deca(); </li></ul><ul><li>b = new Lait(b); </li></ul><ul><li>b = new Citron (b); </li></ul><ul><li>b = new Citron(new Lait(new Deca())); </li></ul>Un Deca avec du lait et du citron De l'extérieure, on ne voit que le citron. Component +Operation() ComposantConcret +Operation() Decorateur +Operation() -monComposant 1 Decorateur1 +Operation() Decorateur2 +Operation()
    152. 152. Decorator : la solution Un Deca avec du lait et du citron Deca Lait Citron La boisson Les ingrédients <ul><li>Calcul du coût de la boisson : </li></ul><ul><li>citron = 0.2(Fait qq chose) </li></ul><ul><li>+super.Operation  </li></ul><ul><li> monComposant.Operation </li></ul><ul><li>lait = 0.3 (Fait qq chose) </li></ul><ul><li>+super.Operation  </li></ul><ul><li> monComposant.Operation </li></ul><ul><li>Deca = 0.5 </li></ul><ul><li>Au retour Total = 1 € </li></ul>Component +Operation() ComposantConcret +Operation() Decorateur +Operation() -monComposant 1 Decorateur1 +Operation() Decorateur2 +Operation()
    153. 153. Decorator : Participants <ul><li>Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Component (Boisson)    </li></ul></ul><ul><ul><ul><li>D é finit l ’ interface pour les objets qui peuvent avoir des responsabilit é s ajout é es dynamiquement. </li></ul></ul></ul><ul><ul><li>ConcreteComponent (deca)   </li></ul></ul><ul><ul><ul><li>D é finit un objet auquel on peut rajouter des responsabilit é s. </li></ul></ul></ul><ul><ul><li>Decorator (Ingredient)   </li></ul></ul><ul><ul><ul><li>Maintient une r é f é rence sur le component et d é finie une interface conforme conforme à celle du component. </li></ul></ul></ul><ul><ul><li>ConcreteDecorator (citron)   </li></ul></ul><ul><ul><ul><li>Ajoute les responsabilit é s au composant. </li></ul></ul></ul>
    154. 154. Decorator : Exemple On utilise l’héritage entre Ingrédient et boisson par Snobisme Boisson::Cout est abstraite Colombia::Cout return 25 (le coût du Colombia sans ingrédient Lait::Cout return le cout du Lait(10) + Le coût de maBoisson Utilisation : Boisson b1 = new Colombia() b1.cout() => 25 Boisson b2 =new Colombia() b2 = new Lait(b2); b2.cout()=> 25 + 10 b2 = new Citron(b2); ….. Colombia Que se passe-t-il si on rajoute la crème Chantilly? Il faut rajouter la classe Chantilly Lait Colombia Citron Lait Colombia
    155. 155. Decorator : Un mauvais exemple(1)
    156. 156. Decorator : un mauvais exemple (2)
    157. 157. Decorator : Exercice les soldats
    158. 158. l ’Adaptateur : le contexte <ul><li>Objectif :L'adaptateur met en conformité l'interface d'une classe au besoin d'une classe cliente. L'adaptateur permet à des classes de collaborer, qui n'auraient pu le faire du fait d'interfaces incompatible. </li></ul><ul><li>Contexte : Ce pattern est particulièrement adapté lorsque les conditions suivantes sont remplies : </li></ul><ul><ul><ul><li>On veut utiliser une classe existante dont l'interface ne coïncide pas avec celle escomptée </li></ul></ul></ul><ul><ul><ul><li>On souhaite créer une classe qui puisse être accédée par des interfaces diverses </li></ul></ul></ul><ul><ul><ul><li>Récupération de vieilleries </li></ul></ul></ul><ul><ul><ul><li>Façade </li></ul></ul></ul>
    159. 159. l ’Adaptateur : Uml et Exemple
    160. 160. L'adaptateur : Participants <ul><li>Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Cible   </li></ul></ul><ul><ul><ul><li>Définit ce qui est appelé par le client </li></ul></ul></ul><ul><ul><li>Adapteur    </li></ul></ul><ul><ul><ul><li>Fait le lien entre ce que veut le client et ce qui existe vraiment </li></ul></ul></ul><ul><ul><li>Adapté    </li></ul></ul><ul><ul><ul><li>C’est ce qui existe vraiment (récupération) </li></ul></ul></ul><ul><ul><li>Client    </li></ul></ul><ul><ul><ul><li>Ne connaît que l’interface de la cible. </li></ul></ul></ul>
    161. 161. L'adaptateur : Exercice Canards oies Canard.Cancaner  &quot;Coincoin&quot; Leurre.Cancaner  &quot;Silence&quot; CanardPlastique  &quot;Pchiff&quot; Oie.Cacarder  &quot; CoincoinCoincoin &quot; Pb : Faire cancaner une troupe de Cancaneur contenant des oies
    162. 162. Composite : Le contexte & UML <ul><li>On utilise le Composite lorsque on veut : </li></ul><ul><li>Représenter une hiérarchie d'objets </li></ul><ul><li>Ignorer la différence entre un composant simple et un composant </li></ul><ul><ul><li>en contenant d'autres (interface uniforme) </li></ul></ul>Comparer avec le décorateur
    163. 163. Composite : Participants <ul><ul><li>Component   (Equipement) </li></ul></ul><ul><ul><ul><li>Déclare l’interface pour les objets de la composition. </li></ul></ul></ul><ul><ul><li>Leaf   (Peripherique) </li></ul></ul><ul><ul><ul><li>Représente les objets feuilles (sans enfants) de la composition. </li></ul></ul></ul><ul><ul><ul><li>Définit le comportement de ces objets. </li></ul></ul></ul><ul><ul><li>Composite   (Container) </li></ul></ul><ul><ul><ul><li>Définit le comportement des objets ayant des enfants. </li></ul></ul></ul><ul><ul><ul><li>Range, stocke les composants enfants </li></ul></ul></ul><ul><ul><li>Client   (pg main) </li></ul></ul><ul><ul><ul><li>Manipule les objets comme un seul en s’appuyant sur l’interface du component. </li></ul></ul></ul><ul><ul><li>Utilisation : </li></ul></ul><ul><ul><li>Fabriquer l'objet (Configurer) </li></ul></ul><ul><ul><li>Le client peut alors appeler Operation () sur l'objet global. </li></ul></ul><ul><ul><li>L'objet global est un composite (ou une feuille) particulier qui prmet de retrouver </li></ul></ul><ul><ul><ul><li>l'ensemble du composite </li></ul></ul></ul>
    164. 164. Composite : Exercice // Configuration Peripherique p1 = new Peripherique (&quot;DVD&quot;, 100,8); Peripherique p2 = new Peripherique (&quot;Disque Dur&quot;, 1000,9); Peripherique p3 = new Peripherique (&quot;Modem ADSL&quot;, 1,8); Peripherique p4 = new Peripherique (&quot;Pentium&quot;, 3500 ,386); Peripherique p5 = new Peripherique (&quot;Ventilo &quot;, 150,15); Container carteMere = new Container (&quot;Carte mère&quot;); carteMere.Ajouter(p4);carteMere.Ajouter(p5); TourDeLuxe tour = new TourDeLuxe (&quot;tour&quot;,100); tour.Ajouter(p1);tour.Ajouter(p2);tour.Ajouter(carteMere); Container ordi = new Container (&quot;IBM&quot;); Ordi.Ajouter (tour);ordi.Ajouter (p3); // Utilisation System.out.println( &quot;le prix total est de : &quot; + ordi.GetPrix() ); Composite Leaf le prix d'un ordi Ordi IBM Tour DVD HD Carte mère Modem Adsl Carte mére Pentium Ventilo
    165. 165. Composite : Solution le prix d'un ordi
    166. 166. Façade : UML
    167. 167. La Façade : le contexte <ul><li>Problème : </li></ul><ul><ul><li>La conception objet implique la décomposition de chaque système complexe en collection d’objets collaborant. </li></ul></ul><ul><ul><li>On veut limiter le couplage des utilisateurs du système avec les éléments de cette décomposition. </li></ul></ul><ul><ul><li>On veut garder la possibilité pour certains client de manipuler l’intérieur du système . </li></ul></ul><ul><li>Solution : On créé un nouvel objet servant de façade à un type d’utilisateur donné et lui offrant des services de haut niveau. </li></ul>
    168. 168. La Façade : les bénéfices <ul><li>Conséquences : </li></ul><ul><ul><li>Découplage d’une partie des clients avec le système considéré. </li></ul></ul><ul><ul><li>Réduction du nombre de classes (complexité) à prendre en compte pour ce client </li></ul></ul><ul><ul><li>Réduction des dépendances à la compilation </li></ul></ul><ul><ul><li>Certains langages (C++ avec les NameSpaces, java avec les packages) permettent de cacher une partie des classes d’un sous-système. </li></ul></ul><ul><ul><li>-> Encapsulation au niveau des systèmes </li></ul></ul>
    169. 169. Façade : Participants <ul><li>Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Façade   (Prêt) </li></ul></ul><ul><ul><ul><li>Connaît les classes du sous système qui sont responsables de </li></ul></ul></ul><ul><ul><ul><li>chaque requête. </li></ul></ul></ul><ul><ul><ul><li>Transmet les requêtes aux classes adéquat. </li></ul></ul></ul><ul><ul><li>Subsystem classes   (VerifApport, VerifSalaire, VerifCaution) </li></ul></ul><ul><ul><ul><li>Implémentent les fonctionnalités du sous système. </li></ul></ul></ul><ul><ul><ul><li>Ne connaissent pas la façade </li></ul></ul></ul>Exemple : Transformation d'une liste en pile
    170. 170. Façade : Exo <ul><li>Apport est au moins de 10% du prêt </li></ul><ul><li>Prêt <= 250 fois le salaire </li></ul><ul><li>Caution >= à 50% du prêt </li></ul>Facade f =new Facade(); System.out.println(f.AccepterPret(100000,1000,20000,55000)); System.out.println(f.AccepterPret(200000,1000,20000,55000)); System.out.println(f.AccepterPret(300000,1000,20000,55000)); true Refus caution trop faible false Refus salaire trop faible Refus caution trop faible Refus apport trop faible false La banque Prêt, salaire, apport, caution
    171. 171. Flyweight : Poids mouche :UML Utilisation : beaucoup de petits objets à se partager à plusieurs. Exemple : les caractères d'un document PluriGleton
    172. 172. Poids mouche : Exemple : une forêt <ul><li>Avantages : </li></ul><ul><ul><li>Réduit le nb d'instances </li></ul></ul><ul><ul><li>Economise la mémoire </li></ul></ul><ul><li>Rmq :tous les arbres doivent </li></ul><ul><li>être gérés de la même manière </li></ul>
    173. 173. Bridge : UML Rmq : ressemble au state
    174. 174. Bridge : Exemple #include <iostream> using namespace std; // .h class Implementor; class Abstraction { protected :Implementor *implementor; public : void SetImplementor(Implementor *value); virtual void Operation();} ; class Implementor { public : virtual void Operation()=0; } ; class RefinedAbstraction : public Abstraction { public :void Operation();}; class ConcreteImplementorA : public Implementor { public : void Operation() ; } ; class ConcreteImplementorB : public Implementor { public : void Operation() ;}; // .cpp void Abstraction::SetImplementor(Implementor *value) {implementor = value;} void Abstraction::Operation() { implementor->Operation(); } void RefinedAbstraction::Operation(){ implementor->Operation(); } void ConcreteImplementorA::Operation(){cout << &quot;OperationA&quot; << endl;} void ConcreteImplementorB::Operation(){ cout << &quot;OperationB&quot; << endl;} int main() { Abstraction *ab = new RefinedAbstraction(); ab->SetImplementor( new ConcreteImplementorA()); ab->Operation(); ab->SetImplementor(new ConcreteImplementorB()); ab->Operation(); }
    175. 175. Les Design patterns Le GoF Création <ul><li>Singleton : un et un seul objet visible par tous </li></ul><ul><li>Fabrication : créer un objet en fonction d'un paramètre </li></ul><ul><li>Fabrique abstraite : créer une famille d'objets tous cohérents </li></ul><ul><li>Monteur : construire un objet en différentes étapes </li></ul><ul><li>Prototype : permet de sp é cifier le type d'objets à cr é er en utilisant une </li></ul><ul><ul><li>instance prototype. Le prototype sera copi é pour cr é er les nouveaux </li></ul></ul><ul><ul><li>objets. </li></ul></ul>
    176. 176. <ul><li>Problème : Une classe nécessite de n’être instanciée qu’une seule fois dans une application </li></ul><ul><li>Contexte : Cette instance unique est utilisable à plusieurs endroits dans l ’application. </li></ul><ul><li>Solution : On va confier à la classe elle-même la responsabilité d’assurer l’unicité de son instance. </li></ul>Le singleton
    177. 177. Le singleton uml
    178. 178. Amélioration du singleton L'usine à singleton : Remplacer singletons par singleton Rmq : En C++, mettre en private le constructeur de copie et l'opérateur d'affectation Rmq : En multi thread, utiliser un mutex ou synchronized.                                                    
    179. 179. Fabrication : Présentation Le problème : If cas1 alors return new c1(); If cas2 alors return new c2(); If cas3 alors return new c3(); Problème de dépendance, ce sous programme dépend de c1,c2,c3…. Et ce problème arrive à chaque fois que l'on veut créer un des ces objets. C'est du code Beurgh! La fabrication va garder et prendre en charge ce code Beurgh, au moins Il sera à un seul endroit. Règle POO : Remplacer le switch par le polymorphisme Fabrication : Garder le switch ce qui évitera de faire des New (et des dépendances)
    180. 180. Fabrication : Problème de dépendance <ul><li>La fabrication va permettre l'inversion des dépendances </li></ul><ul><li>on va encapsuler la création des objets dans une fabrique </li></ul><ul><li>on peut créer plusieurs objets, mais ils sont indépendants les uns </li></ul><ul><ul><li>des autres </li></ul></ul>
    181. 181. Fabrication : exemple les pizzerias(1) L'usine Les produits
    182. 182. Fabrication : exemple les pizzerias(2) : qq celleDeBrest : Pizzeria brest-fromage : Pizza commanderPizza(type: String): pizza creerPizza(item: String): pizza preparer(): void cuire(): void couper(): void emballer(): void [B] Pizza creerPizza (String item) if (item.equals(&quot;fromage&quot;)) { return new PizzaFromageStyleBrest();} else if…… Pizzeria fabriqueBrest = new FabriqueDePizzasBrest(); [A] Pizza pizza = fabriqueBrest.commanderPizza( &quot;fromage&quot; ); [B] System.out.println(&quot;Luc a commandé une &quot; + pizza.getNom() + &quot; &quot;); [A]
    183. 183. Fabrication : le Design pattern
    184. 184. Fabrication : Participants <ul><li>  Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Produit    (Page) </li></ul></ul><ul><ul><ul><li>D é finie l ’ interface des objets cr éé s par la fabrication (Afficher) </li></ul></ul></ul><ul><ul><li>ProduitConcret i    (Introduction,Plan,Conclusion,Dev) </li></ul></ul><ul><ul><ul><li>implementent l ’ interface du produit (CreatePages) </li></ul></ul></ul><ul><ul><li>Createur    (Document) </li></ul></ul><ul><ul><ul><li>D é clare la m é thode &quot;Fabrication(String) : Produit&quot; qui rend un objet de type Produit. </li></ul></ul></ul><ul><ul><li>CreateurConcret     (Report, Resume) </li></ul></ul><ul><ul><ul><li>Surcharge la m é thode Fabrication pour rendre une instance du produit concret. C'est le code Beurgh!!! </li></ul></ul></ul><ul><ul><ul><li>Rmq :la m é thode peut ne pas avoir de param è tre, dans ce cas le code n'est pas beurgh. </li></ul></ul></ul>
    185. 185. Fabrication exercice les livres Fabrique Le produit FabriquePage fab = new FabriquePage(); Page i = fab.CreatePage(&quot;Intro&quot;); i.Afficher(); i=fab.CreatePage(&quot;Conclusion&quot;); i.Afficher();
    186. 186. Fabrication Abstraite : motivation Application IHM Motif IHM windows Application IHM IHM Motif IHM windows L ’application utilise IHM sans savoir si il s ’agit de Motif ou bien de Windows
    187. 187. Fabrication Abstraite : Structure <<instancie>> Application
    188. 188. Fabrication Abstraite : Constituants <ul><li>FabriqueAbstraite (Facultative) </li></ul><ul><ul><li>Déclare une interface contenant les opérations de création d ’objets produits </li></ul></ul><ul><ul><li>abstraits </li></ul></ul><ul><li>Fabrique concrète </li></ul><ul><ul><li>Implémente les opérations de création d ’objets produits concrets </li></ul></ul><ul><li>Produit Abstrait (Facultatif) </li></ul><ul><ul><li>Déclare une interface pour un type d ’objet produit </li></ul></ul><ul><li>Produit concret </li></ul><ul><ul><li>Définit un objet produit qui doit être crée par la fabrication concrète </li></ul></ul><ul><ul><ul><li>correspondante </li></ul></ul></ul><ul><ul><li>Implémente l ’interface de ProduitAbstrait </li></ul></ul><ul><li>Application </li></ul><ul><ul><li>n’utilise que les interfaces déclarées par les classes FabriqueAbstraite et </li></ul></ul><ul><ul><ul><li>ProduitAbstrait </li></ul></ul></ul>
    189. 189. Fabrique Abstraite : Avantages et inconvénients <ul><li>Isoler les classes concrètes </li></ul><ul><li>Faciliter la substitution d ’une famille de produits </li></ul><ul><li>Favoriser le maintien de la cohérence entre les objets </li></ul><ul><li>Gérer de nouveaux types de produits est complexe </li></ul><ul><li>Ne facilite pas la lisibilité </li></ul>Les trains FabriqueAbstraite CreerProduitA() CreerProduitB()
    190. 190. Builder-Monteur Rmq : Le monteur (Builder) est utilisé pour construire différentes sortes d’objets selon une certaine méthodologie (étapes par étapes). Chaque étape dépend du type de l’objet, mais la succession des étapes en est indépendante. (comparer avec le patron de méthode) <ul><li>On utilise le buider lorsque : </li></ul><ul><li>L'algorithme pour créer un objet doit être indépendant des parties qui </li></ul><ul><ul><li>le composent et de la façon de les assembler. </li></ul></ul><ul><li>Le processus de construction permet différentes représentations de </li></ul><ul><ul><li>l'objet construit. </li></ul></ul>
    191. 191. Builder : UML
    192. 192. Builder : Participants <ul><li>Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Builder  (VehicleBuilder) </li></ul></ul><ul><ul><ul><li>Spécifie une interface pour identifier les étapes de la création d’un produit. </li></ul></ul></ul><ul><ul><li>ConcreteBuilder  (MotorCycleBuilder, CarBuilder, ScooterBuilder) </li></ul></ul><ul><ul><ul><li>Construit et assemble les différentes parties d’un objet en implémentant l’interface du Builder. </li></ul></ul></ul><ul><ul><ul><li>Définit le produit final et permet de le retrouver. </li></ul></ul></ul><ul><ul><li>Director  (Shop) </li></ul></ul><ul><ul><ul><li>C’est le client (celui qui utilise le builder). </li></ul></ul></ul><ul><ul><li>Product  (Vehicle) </li></ul></ul><ul><ul><ul><li>Représente le ou les produits fabriqués </li></ul></ul></ul>
    193. 193. Builder : Exemple voici la partie A du produit1 voici la partie B du produit1 voici la partie A du produit2 voici la partie B du produit2
    194. 194. Builder : Exo void main() { Shop shop = new Shop(); VehicleBuilder b2 = new CarBuilder(); VehicleBuilder b3 = new MotorCycleBuilder(); shop.Construct(b2); b2.GetVehicle().Show(); shop.Construct(b3); b3.GetVehicle().Show(); } Usine de véhicules Vehicule type : String moteur : String roue : String porte : String Show() : void VehiculeBuilder GetVehicule() : Vehicule BuildMoteur() : void BuildRoue() : void BuildPorte() : void 1 #vehicule 1 MotoBuilder BuildMoteur() : void BuildRoue() : void BuildPorte() : void MotoBuilder() VoitureBuilder BuildMoteur() : void BuildRoue() : void BuildPorte() : void VoiturBuilder() Shop Construire(p : VehiculeBuilder) : void
    195. 195. Prototype <ul><li>Masque au client les complexités de la création de nouvelles instances </li></ul><ul><ul><ul><li>(new, clone, deserialisation, …) </li></ul></ul></ul><ul><li>Permet au client de générer des objets dont le type n’est pas connu. </li></ul><ul><li>Dans certaines circonstances, la copie d’un objet peut être plus efficace </li></ul><ul><ul><li>que la création d’un objet (memberWiseClone du c#) </li></ul></ul>
    196. 196. Prototype : Participants <ul><li>Les classes et/ou objets participant dans ce pattern sont: </li></ul><ul><ul><li>Prototype  </li></ul></ul><ul><ul><ul><li>Déclare une interface pour se cloner </li></ul></ul></ul><ul><ul><li>ConcretePrototype </li></ul></ul><ul><ul><ul><li>Implémente une opération pour se cloner </li></ul></ul></ul><ul><ul><li>Client </li></ul></ul><ul><ul><ul><li>Créé un nouvel objet en demandant au prototype de se cloner. </li></ul></ul></ul>
    197. 197. DP : Exercice général(1) Les stagiaires ont un nom, un sexe et une catégorie (TM, M, Moyen, B , TB). Ils font des exos qui sont réussis en fonction de leur état (TM =4-10, M=5-10, B=10-15, TB=15-20,Moyen =11) Le prof note aléatoirement (presque) les exos mais favorise les filles. (note en fonction de l’état, plus ou moins un nombre compris entre –10 et + 8, rajouter 2 points pour les filles (sauf pour les très bonnes), la note finale est comprise entre 0-20. Quand un élève obtient une note < 7 son état se dégrade, alors que si il obtient une note > 13 son état s’améliore. Le chef vire celui ou celle qui a la plus mauvaise note à chaque exercice. Bill Gates débauche 2 fois le ou la meilleure, tandis que Google n’en débauche qu’un ou qu’une. D’autres personnes, entreprises ou organismes quelconques pourront bientôt s’ intéresser aux stagiaires. Toutes les notes sont sauvegardées pour chaque élève. Abuser Singleton State Observer Strategie Template methode memento
    198. 198. DP : Exercice général(1) Abuser
    199. 199. DP : Exercice général(2) Les canards <ul><li>Traiter le cas des oies </li></ul><ul><li>Compter les coinscoins </li></ul><ul><li>Comment être sûr de compter tout le monde ? </li></ul><ul><li>Faire cancaner toute une troupe </li></ul><ul><li>Observer de temps en temps et en temps réel le couac de chaque canard </li></ul>Adaptateur Decorateur Fabrique abstraite Composite Observer
    200. 200. Autres Patterns Les classes d'analyse Le raii
    201. 201. Les classes d'analyse <ul><li>Les trois axes d'une classe : </li></ul><ul><ul><li>Boundery - Frontière - Vue </li></ul></ul><ul><ul><li>Contrôleur </li></ul></ul><ul><ul><li>Entity - Objets métier - modèle </li></ul></ul>a2 uc2 uc3 a3 protocole a1 uc1 vue1 vue2 vue3 c1 c2 c3 e1 e2 e3 e4 uc1 vue1 c1 e1 e2 m1 m2 m3 Vopc a1 vue1 c1
    202. 202. RAII : Présentation du pb Tout s’est mal passé et en plus On ne libère pas les ressources out Tout s’est mal passé et en plus On ne libère pas les ressources
    203. 203. (RAII) à la sauce Java (Finally)
    204. 204. RAII à la sauce C++ Selon l'approche RAII, on peut modifier la classe Datafile pour qu'elle fasse le Open() dans son constructeur (avec levée d'exception), et le Close() dans son destructeur. Puis l'on crée une petite classe utilitaire DBLock qui gère le verrouillage de la base :
    205. 205. Patterns et architecture MVC FrameWork Organisation des packages Métriques
    206. 206. Patterns et architecture MVC FrameWork Organisation des packages Métriques
    207. 207. MVC V C M Vue 1 2 3 4 5 <ul><li>(Origine :SmallTalk-Xerox) </li></ul><ul><li>L'utilisateur a fait qq chose (bouton, menu, ….) </li></ul><ul><li>Le contrôleur prévient le modèle </li></ul><ul><li>Modification d'IHM (bouton non disponible, menu grisé, …) </li></ul><ul><li>Le modèle prévient la vue que qq chose est arrivé (changement d'état – Notify) </li></ul><ul><li>La vue demande des informations complémentaires </li></ul><ul><li>Cela permet d'avoir plusieurs vues, plusieurs modèles </li></ul>
    208. 208. MVC : Design pattern composé V C M Composite Stratégie/etat Sujet Observer UpDate()
    209. 209. MVC
    210. 210. Framework : Introduction <ul><li>Définition : </li></ul><ul><li>Un framework est une infrastructure logicielle qui facilite la conception des </li></ul><ul><li>applications par l'utilisation de bibliothèques de classes ou de générateurs </li></ul><ul><li>de programmes, soit dit en quelques mots : un cadre de développement. </li></ul><ul><li>Exemples: </li></ul><ul><li>Struts est un framework java d'interfaçage homme machine pour applications </li></ul><ul><ul><li>web. </li></ul></ul><ul><li>SWING est un framework java d'interfaçage homme machine pour une </li></ul><ul><ul><li>application fenêtrée. </li></ul></ul><ul><li>Les MFC sont un framework C++ d'interfaçage d'une application avec le </li></ul><ul><ul><li>système d'exploitation windows. </li></ul></ul><ul><li>la GTK est un framework C d'interfaçage homme machine avec une </li></ul><ul><ul><li>application fenêtrée, conçu à l'origine pour les systèmes unix et porté </li></ul></ul><ul><ul><li>sur windows. </li></ul></ul><ul><li>java est un framework, Dot.net aussi, Junit est un framework de test …. </li></ul>
    211. 211. Framework : Utilisation <ul><li>Il existe des frameworks de divers types, et ceux-ci sont complémentaires </li></ul><ul><li>un framework réunit l'ensemble des implémentations récurrentes de nos </li></ul><ul><ul><li>développements. Les avantages en sont : </li></ul></ul><ul><ul><li>éviter de recoder encore et toujours les mêmes bouts de codes rébarbatifs, </li></ul></ul><ul><ul><li>agir en un point unique pour modifier l'ensemble du comportement </li></ul></ul><ul><ul><ul><li>applicatif (Par exemple le &quot;look and feel&quot;) faisant profiter toutes les </li></ul></ul></ul><ul><ul><ul><li>applications des avancées du framework, </li></ul></ul></ul><ul><ul><li>assurer la robustesse de ces parties du code (répétitives et essentielles). </li></ul></ul><ul><li>Exemple Spring : </li></ul><ul><ul><li>Java JEE est trop compliqué(pas d'héritage et de polymorphisme avec </li></ul></ul><ul><ul><li>Les EJB.  </li></ul></ul><ul><ul><ul><li>Struts pour la présentation </li></ul></ul></ul><ul><ul><ul><li>Hibernate pour la persistance </li></ul></ul></ul>
    212. 212. Composant <ul><li>Un composant est formé avec: </li></ul><ul><li>Une interface définissant la structure objet nécessaire à la réalisation d'un </li></ul><ul><ul><li>travail (ou plusieurs) </li></ul></ul><ul><li>son implémentation. </li></ul><ul><li>Réunir un ensemble des classes et des interfaces ayant des comportements </li></ul><ul><li>agissant dans le même sens au sein de composants. </li></ul><ul><li>Les divers composants communiquent par le biais d'une Façade. </li></ul>
    213. 213. Organisation des packages
    214. 214. Organisation des packages
    215. 215. Dépendances cycliques : Interface <ul><li>L'application : </li></ul><ul><li>Crée un objet A </li></ul><ul><li>Crée un objet B </li></ul><ul><li>Présente B à A en tant </li></ul><ul><ul><li>que FqqAble </li></ul></ul><ul><li>Présente A à B en tant </li></ul><ul><ul><li>que FqqAble </li></ul></ul>
    216. 216. Métriques (1) · Lines of Code (LOC) : Le nombre total de lignes de code. Les lignes blanches et les commentaires ne sont pas comptabilisés · Number of Static Methods (NSM) : Le nombre de méthodes statiques dans l'élément sélectionné. · Afferent Coupling (CA) : Le nombre de classes hors d'une package qui dépendent d'une classe dans le package · Normalized Distance (RMD) : RMA + RMI - 1: Ce nombre devrait être petit, proche de zéro pour indiquer une bonne conception des parquets. · Number of Classes (NOC) : Le nombre de classes dans l'élément sélectionné. · Specialization Index (SIX) : NORM * DIT / NOM: Moyenne de l'index de spécialisation. · Instability (RMI) : CE / (CA + CE) : Ce nombre vous donnera l'instabilité de votre projet. C'est-à-dire les dépendances entre les paquets. · Number of Attributes (NOF) : Le nombre de variables dans l'élément sélectionné. · Number of Packages (NOP) : Le nombre de packages dans l'élément sélectionné. · Method Lines of Code (MLOC) : Le nombre total de lignes de codes dans les méthodes. Les lignes blanches et les commentaires ne sont pas comptabilisés · Weighted Methods per Class (WMC) : La somme de la complexité cyclomatique de McCabe pour toutes les méthodes de la classe. · Number of Overridden Methods (NORM) : Le nombre de méthodes redéfinies. · Number of Static Attributes (NSF) : Le nombre de variables statique. · Nested Block Depth (NBD) : La profondeur du code
    217. 217. Métriques (2) · Number of Methods (NOM) : Le nombre de méthodes . · Lack of Cohesion of Methods (LCOM) : Une mesure de la cohésion d'une classe. Plus le nombre est petit et plus la classe est cohérente, un nombre proche de un indique que la classe pourrait être découpée en sous-classe. Néanmoins, dans le cas de Javabean, cette métrique n'est pas très correcte, car les getteurs et les settteurs sont utilisés comme seules méthodes d'accès aux attributs. Le résultat est calculé avec la méthode d' Henderson-Sellers : on prend m(A), le nombre de méthodes accédant à un attribut A, on calcule la moyenne de m(A) pour tous les attributs, on soustrait le nombre de méthodes m et on divise par (1-m). · McCabe Cyclomatic Complexity (VG) : La complexité cyclomatique d'une méthode. C'est-à-dire le nombre de chemins possibles à l'intérieur d'une méthode, le nombre de chemin est incrémenté par chaque boucle, condition, opérateur ternaire, # Il ne faut pas que ce nombre soit trop grand pour ne pas compliquer les tests et la compréhensibilité de la méthode. · Number of Parameters (PAR) : Le nombre de paramètres. · Abstractness (RMA) : Le nombre de classes abstraites et d'interfaces divisés par le nombre total de classes dans un package. Cela vous donne donc le pourcentage de classes abstraites par package · Number of Interfaces (NOI) : Le nombre d'interfaces. · Efferent Coupling (CE) : Le nombre de classes dans un packages qui dépendent d'une classe d'un autre package.
    218. 218. Métriques (3) · Number of Children (NSC) : Le nombre total de sous-classes directes d'une classe · Depth of Inheritance Tree (DIT) : Distance jusqu'à la classe Object dans la hiérarchie d'héritage. Graphe de dépendances entre packages http://metrics.sourceforge.net/update
    219. 219. Bibliographie <ul><li>Valtech : </li></ul><ul><li>Management Agile </li></ul><ul><ul><li>Christophe Addinquy (27mn) </li></ul></ul><ul><ul><li>David Gageot (17 mn) </li></ul></ul><ul><li>Xp ca marche vraiment ? (régis Medina –18mn) </li></ul><ul><li>TV4IT : </li></ul><ul><li>Eric Groise </li></ul><ul><li>Michel Cara </li></ul>Vidéo Google : DP & Python : http://www.aleax.it/goo_pydp.pdf (2h)Alex Martelli
    220. 220. Table des matières Les patterns Grass 5 Principes fondamentaux de conception 14 Processus objet (up-xp) 32 Processus objet (test-refactoring) 52 ______________________________________ Les design patterns 70 Les design patterns de comportement 75 Automate 76 Stratégie 86 Patron de méthode 90 Observeur 96 Visiteur 105 Memento 110 Iterateur 115 Chaîne de responsabilité 121 Commande 125 Interpréteur 130 Médiateur 131 Les design patterns de structure 132 Proxy 133 Decorateur 147 Adaptateur 158 Composite 162 Façade 167 Poids mouche 171 Pont 173 Les designs patterns de création 175 Singleton 176 Fabrication 179 Fabrication abstraite 186 Builder 190 Prototype 195 _______________________________________ Autres Patterns 200 Les classes d'analyse 201 Raii 202 Patterns et architecture 205 MVC 207

    ×