Design Patterns Java

  • 6,630 views
Uploaded on

Design patterns …

Design patterns
Observer, Decorateur, State, template methode

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
6,630
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
663
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Design Patterns JAVA Conception d’applications objet B.Vinot
  • 2. Contenu du cours
    • Introduction aux DP
    • Principes fondamentaux de conception
      • Les patterns GRASS
      • Ouverture-Fermeture (OCP)
      • Inversion des dépendances (DIP)
      • Substitution de Liskov (LSP)
      • Séparation des interfaces (ISP)
    • Méthodes de DVP et Processus
      • Up – XP
      • Tests et Refactoring
    • Les design patterns
      • Les DP du GOF (23)
        • Comportement (11)
        • Structure (7)
        • Création (5)
      • Autres Patterns
        • Les Patterns d'analyse
        • Le Raii
    • Organisation
      • MVC
      • Les frameworks
      • Les composants
      • Les packages
      • Métriques
    exercices
  • 3. Pourquoi faire de l'objet(1) ?
  • 4. Pourquoi faire de l'objet(2) ?
  • 5. Introduction aux Design Patterns Les Patterns GRASS General ResponsabilityAssignement Software Patterns
  • 6. Les Patterns : Introduction
    • 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.
    • 1987, Beck et Cunningham définissent des patterns pour interfaces utilisateurs.
    • 1994 : Design Patterns : Elements of reusable object oriented software Gof pour Gang of Four ( Gamma, Helm, Johnson et Vlissides)
    • 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.
  • 7. Les Patterns : Définition
    • 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.
    • Un design pattern doit répondre à certains aspects essentiels :
      • Un pattern a un nom évocateur, qui représente bien l’essence même de son existence. Exemple : le pattern GoF « Singleton »
      • Un pattern résout un problème . Exemple : une classe ne peut avoir qu’une et une seule instance disponible.
      • Un pattern fourni une solution-génie (voir le pattern singleton plus loin)
      • Un pattern doit être expliqué ( documentation-uml )
  • 8. Exemple : Les Patterns Grasp
    • C’est presque du bon sens
      • L’expert (affectation des responsabilités)
      • Le créateur
      • Faible couplage
      • Forte cohésion
      • Contrôleur
  • 9. Le pattern GRASP : Expert
    • Qui fait quoi :
    • 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 ).
      • on ne peut exiger d’un réfrigérateur qu’il fasse radiateur et range-disques
      • Donner des définitions (c'est très difficile)
      • int i; // variable i entière
  • 10. Le pattern GRASP : Créateur
    • Qui crée qui? :
    • Ce pattern consiste en la détermination de la responsabilité de la création d’une instance d’une classe par une autre.
      • Une classe A agrége des instances de la classe B
      • Une classe A contient des instances de la classe B
      • Une classe A utilise des instances d’une classe B
      • Une classe A possède les données nécessaires à l’initialisation des instance de classe B, etc.…
      • Variables globales!
      • Notion de configurateur
      • Déléguer la fabrication à qq d’autre!
      • Persistance (JDBC,DAO)
  • 11. Le pattern GRASP : Couplage
    • 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.
    • Les objets sont couplés (paresseux)
    • Un objet qui est connu de personne est inutile.
    • Un objet qui connaît personne ne fait pas grand chose (sauf Utility)
    • Parler à des classes abstraites plus tôt qu’à des classes concrètes
  • 12. Le pattern GRASP : Cohésion
    • Esprit de famille
    • La cohésion mesure le degré de spécialisation des responsabilités d’un composant / classe.
    • La cohésion médiocre altère la compréhension, la réutilisation, la maintenabilité et subit toute sorte de changements.
    • Exception pour Corba, RMI, …..(pb de granularité)
  • 13. Le pattern GRASP : Contrôleur
    • Le contrôleur contrôle. Il est entre la vue et les entités (MVC)
    • Une classe Contrôleur doit être crée si elle répond à l’un des cas suivants
      • La classe représente une contrôleur de façade , c’est à dire l’interface d’accès à l’ensemble d’un système.
      • 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.
      • Un contrôleur contient :
        • Ce qui ne concerne pas la vue
        • Ce qui ne concerne pas les entités (Expert)
  • 14. Principes fondamentaux de conception Ouverture-Fermeture OCP Inversion des dépendances DIP Substitution de Liskov LSP Séparation des interfaces ISP
  • 15. Les objectifs du DESIGN
    • Éviter les phénomènes de dégénérescence de l'application
    • Du point de vue du design, trois risques principaux pénalisent les activités de développement :
      • La rigidité : chaque évolution est susceptible d'impacter de nombreuses parties de l'application  Extensibilité.
      • La fragilité : la modification d'une partie de l'application peut provoquer des erreurs  Robustesse
      • L' immobilité : il est difficile d'extraire une partie de l'application pour la réutiliser dans une autre application.
        •  Réutilisation
  • 16. Gestion des évolutions et des dépendances entre classes
    • Principe d’ouverture/fermeture Open-Closed Principle (OCP) Touche pas à mon code
    • Principe de substitution de Liskov Liskov Substitution Principle (LSP) Les enfants doivent respecter le contrat
    • Principe d’inversion des dépendances Dependency Inversion Principle (DIP) Utiliser des Interfaces
    • Principe de séparation des interfaces Interface Segregation Principle (ISP) Diviser les interfaces
  • 17. Exemple : utilisation de la délégation abstraite ( OCP )
    • 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 :
  • 18. L’application de l’OCP est un choix stratégique ( OCP )
    • 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.
    • 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.
    • Il convient donc d'identifier correctement les points d'ouverture/fermeture de l'application, en s'inspirant :
      • des besoins d'évolutivité exprimés par le client,
      • des besoins de flexibilité pressentis par les développeurs,
      • des changements répétés constatés au cours du développement .
    • La mise en oeuvre de ce principe reste donc une affaire de bon sens.
  • 19. Exemple : ( OCP ) Personne nom : string age : int Personne(n : string, a : int) Appl1 Appl2 BD Appl3 Avec adr
    • Rajouter un attribut
      • Rajouter un constructeur
      • Rajoute un paramètre au constructeur
    • Faire une nouvelle classe PersonneAdr
      • Rajouter une méthode getAdr même ds Personne
    ID nom age
  • 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
    • Jouer sur les méthodes plus tôt que sur les attributs
    • Les gains :
    • 2 versions dans le même exécutable
    • pas besoin de faire de VNR (faites la quand même)
    Appl3
  • 21. Principes de substitution de LISkOV ( LSP )
    • 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.
    • Hériter d’une interface
    • 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.
  • 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. Principes d’inversion des dépendances ( DIP )
    • 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;
  • 24. Principes d’inversion des dépendances ( DIP )
    • Cela paraît naturel au premier abord mais pose en réalité deux problèmes essentiels :
      • Les modules de haut niveau doivent être modifiés lorsque les modules de bas niveau sont modifiés.
      • 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.
    • La relation de dépendance doit être inversée :
      • les modules de bas niveau doivent se conformer à des interfaces définies et utilisées par les modules de haut niveau .
  • 25. L’abstraction comme technique d’inversion des dépendances ( DIP )
    • Considérons deux classes A et B, A utilisant B comme indiqué sur le schéma ci-dessous :
    Pour inverser la dépendance de A vers B, on introduit une classe d'interface I dont dérive B comme suit :
  • 26. Principes de séparation des interfaces ( ISP )
    • Pollution d'interface par agrégation de services
      • On retrouve dans la plupart des designs quelques classes qui rendent plusieurs services simultanément, comme l'illustre le schéma ci-dessous :
  • 27. Principes de séparation des interfaces ( ISP )
    • L'inconvénient de ce genre de cas est que tous les clients ont une visibilité sur tous les services rendus par la classe :
      • Chaque client voit une interface trop riche dont une partie ne l'intéresse pas,
      • Chaque client peut être impacté par des changements d'une interface qu'il n'utilise pas.
    • Solution : séparation des services de l'interface
      • Le principe de séparation des interfaces stipule que chaque client ne doit &quot;voir&quot; que les services qu'il utilise réellement
  • 28. Principes de séparation des interfaces ( ISP )
  • 29. Techniques de séparation ( ISP )
    • Il existe deux techniques principales de mise en pratique de l'ISP :
      • L'héritage multiple,
      • Le Design Pattern &quot;Adapter&quot;.
  • 30. Séparation par héritage multiple ( ISP )
    • 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 :
  • 31. Séparation par adaptateur ( ISP )
    • Lorsque l'héritage multiple n'est pas possible, les services peuvent être représentés par des classes d'adaptation :
  • 32. Processus Objet UP XP-Agile Winston Royce. Managing the Development of Large Software Systems . 1970
  • 33. UP: Caractéristiques essentielles
    • Caract é ristiques essentielles du processus unifi é :
    • - Le processus unifi é est à base de composants ,
    • Le processus unifi é utilise le langage UML
      • (ensemble d'outils et de diagramme),
    • - Le processus unifi é est pilot é par les cas d ’ utilisation ,
    • Centr é sur l ’ architecture
      • (plate-forme, performances, r é utilisation, ind é pendante
      • des UC, Y, … )
    • - It é ratif et incr é mental .
    UP  RUP  XUP
  • 34. UP & les modèles UML (1)
  • 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. UP & L'organisation matricielle
  • 37. Processus Objet XP-Agile Extrem programing La programmation extrême Les processus agiles
  • 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 :
    • Les spécifications sont définies au début du projet, alors qu'on en sait encore peu sur le sujet,
    • Les spécifications différencient rarement ce qui est important de ce qui ne l'est pas,
    • L'application se rigidifie progressivement en un produit &quot;final&quot; souvent difficile à faire évoluer et à maintenir,
    • 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.
  • 39. Les méthodes agiles
    • Année 80 : RAD (100 jours)
    • Année 90 : XP (Chrysler) et DSDM (Angleterre)
      • ( Dynamic Software Development Method )
    • 2001 : Le manifeste Agile
      • individus et interactions plutôt que processus et outils
      • développement logiciel plutôt que documentation exhaustive
      • collaboration avec le client plutôt que négociation contractuelle
      • ouverture au changement plutôt que suivi d’un plan rigide
  • 40. Les valeurs d' XP (1)
    • Communication
    • 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.
    • 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.
    • XP rend accessible à tous les intervenants l'ensemble des indicateurs d'avancement du projet.
    • Feedback
    • 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.
    • XP met en place des batteries de tests d'acceptation qui mesurent concrètement l'avancement des développements.
    • 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.
  • 41. Les valeurs d' XP (2)
    • Simplicit é
    • XP s'assure que seules les fonctionnalit é s demand é es par le client sont impl é ment é es.
    • 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.
    • Courage
    • XP donne au jour le jour une transparence maximale sur l' é tat d'avancement r é el du projet.
    • 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.
  • 42. Binôme (1)
    • Binôme
      • Bien perçu des programmeurs
      • Garantit l’homogénéité du code, le respect des règle de codage
      • Responsabilité et connaissance collective du code
      • Facilite la communication (moins de situation de blocage)
      • Pousse à bien faire (Motivation et satisfaction)
      • Phase d'adaptation de 2 semaines
      • Ne pas accepter ceux qui refusent
      • Le code est de meilleur qualité (ils pensent + aux cas particuliers)
    • Stand up meeting chaque soir
      • Faire tourner les binômes
      • Répartition des compétences
  • 43. Binôme (2)
    • Exploration d’un problème (Spike - CrcCards)
    • Nom des objets (bonne compréhension)
      • Prendre le temps de bien le faire (Métaphore local)
    • Documenter le code
      • Pas de documentation mais un code bien commenté (Déclaration)
    • Espace de travail
      • Espace de développement central
      • Bureautique en périphérie
      • Grande table de réunion dans le bureau
      • Grand écrans pour le développement
      • Tout le monde se voit (mobilier spécifique?)
  • 44. TU
    • Tests unitaires
      • Aide à la conception détaillé
      • Systématiquement avant le code (inhabituelle)
      • Ne doit pas passer au début (Iconoclaste?)
      • Ne pas développer plus que ce qui est nécessaire pour le test
      • Auto-vérifiant (18000 tests passés en 15 mn-tests passés de 15 mn
        • À 20 secondes)
      • Tous les tests de tous les modules doivent passer sans erreur avant
        • d’intégrer le code
      • Super aide à la non régression, au changement de conception et
        • au remaniement
      • Cela peut être mis en œuvre hors de XP
  • 45. La Planification
    • La planification collective en début d’incrément (Une journée)
      • Incrément de trois semaines
      • Lecture et explications des user stories (cas d’utilisation)
      • Grandes lignes de la conception
      • Définition et évaluation des tâches
    • Évaluation en temps idéal + Load factor
      • Évaluation en deux groupes. Le minimum est choisi si aucune
        • difficulté n’a été oubliée.
  • 46. Conditions d’application
    • Il faut :
    • Une équipe qui s’entende bien et réduite (12 max)
    • Développement mono site
    • Programmation par composants
    • Que le client participe et adhère
    • Il ne faut pas:
    • Une spécification complète et détaillée du futur système
    • Mesurer la qualité de la documentation au poids
  • 47. Les principes de base
    • Seul le code source fait foi, il possède une odeur
    • L’important c’est le programmeur
    • Faire le plus simple possible
    • Restructurer dès que nécessaire
    • Pratiquer la programmation par paire
    • Les spécifications sont des « histoires d’utilisateurs »
    • La planification est un jeu
    • Livrer fréquemment
    • Tester encore, toujours et tout le temps
    • Être courageux
  • 48. histoires d’utilisateurs
    • Des descriptions rédigées par les utilisateurs (clients)
    • Pour chaque histoire :
      • le client donne :
        • Priorité
        • Tests d’acceptation
      • Les développeurs :
        • Estimation de la charge de la réalisation
          • (l’histoire peut être découpée en tâches)
    Une histoire est une unité de livraison RMQ : Une histoire est un très gros use case
  • 49. La planification est un jeu XP tente de désamorcer les conflits Un vrai dialogue Client Développeur
    • Définition des itérations :
    • Histoires avec les priorités
    • Proposer des choix au client
  • 50. Être courageux
    • Standup meeting
    • Choisir des tâches que l’on ne sait pas faire
    • Accepter d’expliquer aux autres ce que l’on sait
    • S’arrêter de développer pour faire du refactoring
    • Accepter de ne pas être responsable, alors qu’on est plus fort
    • Ne pas avoir les yeux plus gros que le ventre
  • 51. Déroulement Scrum
  • 52. Processus Objet Tests Refactoring
  • 53. Test et Junit
  • 54. Junit
  • 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. Junit : lancement du test Regrouper les tests : Sur un projet ou un package Faire new JunitTestSuite (Other) Junit4
  • 57. Tests : Les couches Blabla Objets métier CTRL BD Serialisation
    • Les objets métier offrent des interfaces pour les IHM (le CTRL)
    • En analyse : Les trois axes d' une classe
    String global
  • 58. Couverture de test
  • 59. Le Refactoring :Principes (1)
    • Programmer au plus simple
    • Faire du refactoring tout le temps (comme le ménage)
    • Faire des itérations spéciales
    • S’assurer que :
      • Les tests existent
      • Ils sont OK
    • Faire des petites choses
      • Renommer
      • Découper
      • Déplacer
  • 60. Le Refactoring :Principes (2)
    • Mettre en place des design patterns
    • Composer des design patterns
    • Accepter  de  &quot; refactorer &quot;  le code des autres
    • Remonter des interfaces
    • Utiliser des Interfaces ou des classes abstraites
    • Utiliser les outils de refactoring (Eclipse)
  • 61. Le refactoring dans Eclipse (1)
    • 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.
    • Rename : Renomme l'élément sélectionné.
    • 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)
    • 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.
    • Convert Local Variable to Field : Transforme une variable locale, définie dans une méthode, en champ de classe
  • 62. Le refactoring dans Eclipse (2)
    • 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.
    • 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é.
    • 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
    • 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.
  • 63. Le refactoring dans Eclipse (3)
    • 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.
    • Encapsulate Field : Remplace toutes les références à un champ de classe, par des méthodes get et set pour ce champ.
    • 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.
  • 64. Le refactoring dans Eclipse (4)
    • 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. .
  • 65. Refactoring : exercice(1) Vidéo-Club
    • Un film
    • une catégorie (enf, norm, nouv)
    • un titre
    • Une location
    • concerne un film
    • une durée
    • Coût de la location
    • norm : 2 + 1.5 par jour au de la
    • du deuxième jour
    • nouv : 3 par jour
    • enf : 1.5 + 1.5 par jour au de la
    • du troisième jour
    Bonus : Chaque location donne un point, si une nouveauté est louée plus qu'un jour, alors un point supplémentaire.
  • 66. Refactoring : exercice(2) Vidéo-Club
  • 67. Refactoring : exercice(3) Vidéo-Club
  • 68. Refactoring : correction Vidéo-Club
  • 69. Les Design patterns Le GoF Comportement Structure Création
  • 70. Les Design Patterns
    • Problème: Comment allouer des objets en mémoire ?
    • Contexte: un grand nombre d ’objets alloués en mémoire virtuelle.
    • 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.
    • Alexander writes:
      • Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.
    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. Présentation des patrons de conception
    • 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.
    • Le concept n’est pas spécifique à l’informatique puisque son domaine d’origine est l’architecture.
    • Les patrons de conception introduisent la réutilisation des expériences de conception logicielle
    • 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.
  • 72. Description des patrons de conception
    • 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.
    • Cette description comporte typiquement les éléments suivants :
        • Un nom permettant de l’identifier
        • Le problème et son contexte
        • Les éléments de solution et leurs relations
        • Les bénéfices et conséquences induits
    • Le catalogue le plus connu est celui de Erich Gamma qui recense dans son livre quelques 23 modèles de conception orientée objet
  • 73. Classification des patterns Création Comportement Structure
  • 74. Les Design patterns de comportement (1)
    • State : un objet réagit selon son humeur
    • Stratégie : Faire une chose de différentes manières
    • Template Methode : Faire une chose de différentes manières
    • (avec une recette de base)
    • Observer : certains sont intéresses par ce que je fais, mais pas tout le
      • temps
    • Visiteur : Rajouter une responsabilité à une classe avec des sous
      • traitements identiques
    • Memento : sauvegarder un objet
    • Iterateur : Balayer une collection
    • Chaîne de responsabilité : un élément est attendu par un grand nombre
      • d'objets
  • 75. Les Design patterns de comportement (2)
    • Commande : encapsule une requête dans un objet, et permet les files
      • d'attentes, les journalisassions , et retours en arrière (undo).
    • Médiateur : définit un objet qui encapsule la manière dont un
      • ensemble d'objets interagissent.
    • Interpréteur : définit un langage ainsi que sa grammaire, et fournit un
      • interpréteur pour utiliser la représentation du langage.
  • 76. l ’Automate : contexte
    • 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.
    • Contexte : Fournir un approche systématique d ’implantation des diagrammes d ’états UML
    • 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.
  • 77. State : Préambule
    • Soit des stagiaires qui réagissent selon leur humeur :
    • Si on leur demande de travailler:
      • Si c’est le matin, ils écoutent.
      • Si c’est l’après midi, ils font la sieste.
      • Si c’est midi juste, ils grognent……
    • Si on leur demande de faire un exercice ……….
  • 78. State : UML Client Etat +Op1(Context) +Op2(Context) +Op3(Context) * Etat1 +Op1(Context) +Op2(Context) Etat2 +Op2(Context) +Op3(Context)
  • 79. State : Participants
    • Les classes et/ou objets participant dans ce pattern sont:
      • Context  
        • Défint la classe principale utilisée par le client
        • Garde une instance de la sous classe state pour définir l’état courant.
      • Etat 
        • Définit l’interface des différents états.
      • Concrete State
        • Chaque sous classe implémente l’interface du State conformément à ce qui est faisable dans cet état.
  • 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. 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. 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. State + Singleton
  • 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. State : Remarques
    • Remarques :
      • Les états concrets peuvent posséder une référence à l’objet (possibilité pour l ’état concret de manipuler les attributs de l ’objet)
      • Le changement d’état peut être gérer par l’objet lui-même ou par les états concrets.
    • Conséquences :
      • De nouveaux états peuvent être facilement ajoutés
      • Les transitions d’état sont plus explicites
      • Si les états concrets n’ont pas d’états internes (variables), alors ils peuvent être partagés (singleton)
    Plus simple
  • 86. Stratégie : contexte
    • On utilise Stratégie lorsque :
    • De nombreuses classes associées ne diffèrent que par leur comportement.
    • Ce pattern permet de configurer une classe avec un comportement parmi
      • plusieurs.
    • On a besoin de plusieurs variantes d'algorithme.
    • Un algorithme utilise des données que les clients ne doivent pas
      • connaître.
  • 87. Stratègie : UML
  • 88. Stratègie : Participants
    •      Les classes et/ou objets participant dans ce pattern sont:
      • Strategie  (SortStrategy)
        • Déclare une interface commune pour tous les algorithmes supportés.
      • ConcreteStrategie  (QuickSort, ShellSort, MergeSort)
        • Implémente un algorithme conformément à l’interface de la Strategie.
      • Context  (SortedList)
        • Est configuré avec un objet concreteStrategy
        • Maintient une référence sur un objet Strategy
        • Peut définir une interface qui permet à la stratégie d’accéder ses données.
  • 89. Stratègie : Exo
    • Renvoyer
    • Celui qui gagne le plus
    • Celui qui prend le plus de vacances
    • Celui qui ……
    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. Patron de méthode : principe
    • C’est du code (un algorithme cablé pour toutes les sous classes)
      • qui est fait principalement par appel de méthodes virtuelles
      • et abstraites .
    • Ressemble à un template C++
      • Mécanismes très différents
      • Plus souple
        • Les traitements peuvent diverger d’une sous classe à l’autre
          • alors que cela est impossible avec les templates
      • Plus simple
    • C’est du code en avance sur les futures sous-classes
    • Avantage : Découpe des méthodes en méthodes plus fines
  • 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. 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. Patron de méthode TravaillerMatin(); Dejeuner(); TravaillerApresMidi(); Loisir(); Dormir(); TravaillerMatin: Dormir(); TravaillerApresMidi: AllerANPE(); Loisir: Pleurer();
  • 94. Patron de méthode : Exo : Impôts
    • Nouvelle loi de finance :
    • Impôts sur le revenu :
        • Couple avec enfants : Frais : -20 % moins 1000 par enfant IR = reste * 2/12
        • Couple sans enfant : Frais : -20 % IR = reste * 3/12
        • Célibataire Frais : -10 % IR = reste * 4/12
    • Taxe d’habitation
        • Couple avec enfants : Un loyer moins 50 par enfants
        • Couple sans enfant : Deux loyers
        • Célibataire Deux loyers + 1000
    • ISF
        • Couple avec enfants : 20% de (ISF-300000) si > 300000 sinon 0
        • Couple sans enfant : 20% de (ISF-200000) si > 200000 sinon 0
        • Célibataire 20% de (ISF-80000) si > 100000 sinon 0
    • Tout le monde profite d’un parachute (non golden) qui s’élève au max à 50% des revenus.
    • Un célibataire libéral paye un surplus d’impôt de 5000 indépendamment du parachute fiscal
    • TVA sociale augmente de 5 points
    (Calcul sur le revenu annuel) Déclaration : Revenu annuel-loyer mensuel-fortune-nombre d’enfants
  • 95. Patron de méthode : Exo : Impôts
  • 96. l’Observer : le contexte
    • 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.
    • 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
    • Solution : Implantation d’une interaction entre objets de type souscription-diffusion
  • 97. l’Observer : la solution
    • le Sujet : Définit un mécanisme général de gestion des objets en dépendance
        • Maintient la liste des Observeurs à l ’aide des méthodes attach(Observer*) et detach(Observer *)
        • Fournit le mécanisme permettant de prévenir les Observeurs lorsqu ’un changement d ’état se produit
    • l ’Observeur : Définit l ’interface update() permettant d ’être prévenu d ’un changement d ’état
    • le SujetConcret : Sous-classe de Sujet, gère son état interne et invoque notify() lorsque son état change
    • les Observeurs Concrets : Sous-Classes d ’Observeur, implentent l ’interface update() en fonction de leur besoin
  • 98. l’Observer : UML Réutilisable Rmq : souvent UpDate contient des paramètres (evt, le sujet, l'état du sujet, …)
  • 99. l ’Observer : la dynamique
  • 100. Observer : Participants
    •   Les classes et/ou objets participant dans ce pattern sont:
      • Sujet    (Stock)
        • Conna î t les observateurs. Plusieurs observateurs peuvent observer un même sujet. Cela peut être dynamique.
        • Offre un moyen d ’ attacher et de d é tacher les observateurs.
      • SujetConcret   (IBM)
        • C ’ est lui qui contient l ’ information observable.
        • Pr é vient les observateurs quand l ’ information change.
      • Observer    (IInvestor)
        • C ’ est juste la d é finition de l ’ interface.
      • les Observeri    (Investor)
        • Garde une r é f é rence sur le Sujet concret
        • impl é mente l ’ interface de l ’ observer pour aller chercher l ’ information.
  • 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. 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. 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. Observer : Exercice2 Les villes
  • 105. Visitor
    • Rajouter une (ou plusieurs) méthode à un objet
    • (sans la rajouter) !!!!
    • A utiliser quand une classe ne sait pas ce qu’elle veut et
    • qu’elle risque de vouloir beaucoup de choses.
    • La classe fait déjà beaucoup de petites choses
    • L'objet visité accepte le visiteur (Accept (Visitor v))
    • Il dit alors à v de visiter (v.Visit())
    • v fait son travail
  • 106. Visitor : UML
  • 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. 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()); }
    • Une entreprise veut soit :
    • augmenter les salaires de 10%
    • donner 2 jours de vacances supplémentaires
    • d'autres combinaisons TBD
  • 109. Visitor :correction Salaire Vacances
  • 110. Mémento : UML La classe à surveiller-----La mémoire----Le programme client (main) UnDo-ReDo
  • 111. Mémento : Participants
      • Memento 
        • Stock l’état interne (tout ou partie) de l’objet Origine.
        • 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.
      • Originator 
        • Crée un memento contenant une photo de lui même à un instant donné (sauvegarde).
        • Utilise le memento en cas de restauration.
      • Caretaker 
        • Est responsable de la gestion des sauvegardes-restauration
        • Il ne regarde jamais le contenu interne du Memento
  • 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. 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. 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. L’Itérateur-Iterator : le contexte
    • Balayer des collections
    • Problème, pas d'iterateur pour les tableaux, mais on peut
      • le développer
  • 116. Itérateur: UML
  • 117. Iterateur : Participants
    • Les classes et/ou objets participant dans ce pattern sont:
      • Iterator  
        • définit une interface pour accéder et traverser les éléments d’une collection.
      • ConcreteIterator  (Iterator)
        • implémente l’interface Iterator.
        • garde trace de la position courante dans la collection.
      • Aggregate  (AbstractCollection)
        • définit une interface pour créer (obtenir) un objet Iterator.
      • ConcreteAggregate  (Collection)
        • Implémente l’interface de création et rend une instance d’un objet ConcreteIterator
  • 118. Itérateur : remarques
    • Un itérateur est dit robuste, s’il garantit que insertions et suppressions n’interféreront pas avec le parcours.
    • Problème Multithread
    • Des opérations supplémentaires peuvent être utilisées : SauteA, Précédent…
    • Une classe ne doit avoir qu'une seule responsabilité (au sens large)
    • sinon, il y a plus
    • de risques de
    • changement
    • Java 5 (generics)
      • For (Object o : Collection)
      • { o.fqq();}
  • 119. Itérateur & Composite
    • Itérateur interne
      • On peut balayer un composite en utilisant l'opération prévue
      • (exempleGetCout()).
      • Partir de la racine et simplement
      • appeler la méthode
    • Itérateur externe
      • Il faut l'écrire
      • Mise en œuvre d'une pile
      • Utiliser des iterator normaux pour les
      • éléments composés
  • 120. Itérateur : Exercice
    • Reprendre l'ordinateur du Composite
    • Mettre les différents éléments dans des tableaux
    • Faire un iterateur de tableau
    • Faire un itérateur externe pour l'ensemble
    le prix d'un ordi
  • 121. Chaîne de Responsabilité
    • Polymorphisme et récursivité
    • Utiliser la pattern Chaîne de responsabilité quand vous voulez donner à plus d’un objet une
      • chance de traiter une requête
    • L’ensemble des objets est construit dynamiquement
    • Avantages :
      • Découple l’émetteur de la requête de ses récepteurs
      • Simplifie l’objet qui envoie la requête car, il n’a pas besoin de connaître la structure de
        • la hiérarchie utilisée, ni de conserver des références directes sur les membres.
      • Permet d’ajouter, modifier , supprimer des responsabilités en changeant la hiérarchie
    • Exemples :
      • Machine à trier les pièces
      • Traitement des mails
        • lettres de fan => PDG
        • réclamations => Service juridique
        • demandes de modification => R&D
        • publicité => Poubelle
  • 122. Chain of Resp : UML
    • Deux temps :
    • Configurer la hiérarchie
    • Faire des demandes
  • 123. Chain of Resp : Participants
    •   Les classes et/ou objets participant dans ce pattern sont:
      • Handler   (Approver)
        • définit une interface pour gérer les requêtes
        • (optionnel) implémente le lien successeur
      • ConcreteHandler   (Director, VicePresident, President)
        • Gère une requête si il en est responsable
        • Peut accéder à son successeur
        • Passe la requête à son successeur si il ne peut pas la traiter
      • Client   (ChainApp)
        • Provoque le premier appel de la requête vers un ConcreteHandler de la chaîne des successeurs.
  • 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. Command
    • Faire faire qq chose à un objet sans le connaître
    • Commander qq chose sans connaître celui qui le fera
    • Réduction du couplage
    • Permet :
      • les logs (historiques)
      • les undo-redo (avec ou sans Memento)
      • temporisation d'action
      • mise en file d'attente
      • contrôle
      • souvent utiliser avec un composite pour exécuter plusieurs
        • commandes (notion de macro commande)
  • 126. Command : UML Configurateur Utilisateur
  • 127. Command : Participants
    •   Les classes et/ou objets participant dans ce pattern sont:
      • Command
        • définit une interface pour faire faire qq chose (Execute)
      • ConcreteCommand
        • Connaît celui qui fait qq chose (Receiver)
        • Implémente la méthode Execute en faisant faire le travail au
          • receiver.
      • Receiver
        • Fait le travail, il ne connaît personne
      • Client   
        • Connaît la ou les commandes concrètes et les initialisent avec un receiver.
      • Invoker
        • Fait faire qq chose sans connaître ni les commandes concrètes ni les receivers (seulement l'interface)
  • 128. Command : Exo Architecture
    • Un architecte (client)
    • Chef de chantier (Invoker)
    • Plâtrier (Receiver)
    • Maçon (Receiver)
    • Couvreur (Receiver)
    • Couvreur véreux (Receiver)
    • Faire les murs externes (Action)
    • Faire les murs internes (Action)
    • Faire le toit (Action)
    • Faire des recettes (DeAction)
    • Construire (Command)
    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. 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. Interpreter : UML
  • 131. Mediator : UML Mediator ConcreteMediator Colleague +mediator bouton liste textArea Controleur menu Rmq :Façade-Observer
  • 132. Les Design patterns Le GoF Structure
    • Proxy : cacher la complexité d'un objet
    • Décorateur : Rajouter une responsabilité à une classe sans changer l'interface
    • Adaptateur : Adapter un objet à un autre
    • Composite : permet de traiter une structure d'objets de manière uniforme
      • (Des feuilles et des nœuds)
    • Façade : Représenter, regrouper et diriger un ensemble d'objets
    • Poids mouche : Partager de nombreux minis objets
    • Pont : permet de différencier une abstraction de son implémentation,
      • permettant à chacune d'évoluer indépendamment.
  • 133. Proxy :le contexte
    • On utilise un proxy :
    • pour référencer un objet par un moyen plus complexe qu'un &quot;pointeur&quot;.
    • pour rajouter, modifier, supprimer des responsabilités à un objet sans en
      • changer ni la structure interne, ni l'interface.
    • Il existe plusieurs types de proxy :
    • Proxy distant (RMI)
    • Proxy virtuel pour le cas de chargement d'objet très volumineux
    • Proxy de protection
    • Proxy de référence intelligente :
      • Persistence
      • Comptage de référence
    • ……… .
  • 134. Proxy : UML Proxy.Operation1() { fait qqchose….. leSujet.Operation1();} Proxy.Proxy(Sujet param){ leSujet = param;}
  • 135. Proxy : Participants
    •   Les classes et/ou objets participant dans ce pattern sont:
      • Proxy  
        • remplace l ’ objet r é el et pointe vers celui-ci
        • Operation1 fait le traitement suivant:
          • Proxy distant : fabrique un message et l'envoie au Sujet r é el via
            • un skeleton. Le proxy s'appelle alors un stub.
          • Proxy de protection : v é rifie si l'appelant a les droits pour ex é cuter
            • l'op é ration, il l'accepte ou la refuse.
            • On peut utiliser l'API InvocationHandler
          • Proxy virtuel : exemple chargement d'une image. Le proxy lance
            • le chargement de l'image et affiche le % de temps restant.
            • Lorsque l'image est charg é e, alors il l'affiche.
          • Proxy de r é f é rence intelligente : exemple smart pointer du C++
      • Sujet   
        • D é finit l ’ interface commune au proxy et au sujet r é el.
      • SujetReel
        • D é finit l ’ objet r é el que le proxy repr é sente .
  • 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. Proxy Distant :RMI (1)
    • Utilisation de rmi ( import java.rmi.* )
    • Créer une interface distante:
      • public interface Sujet extends Remote
      • public void Operation1 () throws RemoteException ;
      • s'assurer que les paramètres et valeur de retour sont serialisable
    • Créer une implémentation distante SujetReel
      • public class SujetReel extends UnicastRemoteObject implements Sujet
      • Ecrire un constructeur sans argument,avec excpt
        • public SujetReel () throws RemoteException vv
      • Enregistrer le service
        • try {
        • SujetReel leSujetReel = new SujetReel ();
        • naming . rebind ( &quot; BonjourDeLoin &quot; , leSujetReel );
        • } catch ( Exception e) {…}
  • 138. Proxy Distant :RMI (2)
    • Générer le stub (proxy) et le skeleton
      • lancer rmic sur le fichier SujetReel.java
      • rmic SujetReel
    • Exécuter rmiregistry (outil pour l'enregistrement)
      • en tapant simplement dans une fenêtre dos rmiregistry
    • Démarrer le service en tapant : java SujetReel
    • Le client peut alors utiliser le service
      • Sujet monSujet = (Sujet) Naming . Lookup
      • (&quot;rmi://127.0.0.1/ BonjourDeLoin&quot;);
      • monSujeT.Operation1();
    Proxy Distant :Exercice Bonjour de loin
  • 139. Proxy de protection :exercice (1) le patron et les grouillots
  • 140. Proxy de protection :exercice (2) le patron et les grouillots
  • 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. Proxy de protection avec InvocationHandler
  • 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. 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. Proxy invocationHandler :Exercice(1) le club de rencontres Rmq basedonnees est une Hashtable ---------------------------------------------- Passage difficile :
  • 146. Proxy invocationHandler :Exercice(2) le club de rencontres
  • 147. Decorator : Présentation Problème : nombreux héritages Solution : Héritage  héritage + agrégation (poupée russe)
  • 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. 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. 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. Decorator : la solution construction Deca Lait Citron La boisson Les ingrédients
    • Fabrication de l'objet :
    • Boisson b= new Deca();
    • b = new Lait(b);
    • b = new Citron (b);
    • b = new Citron(new Lait(new Deca()));
    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. Decorator : la solution Un Deca avec du lait et du citron Deca Lait Citron La boisson Les ingrédients
    • Calcul du coût de la boisson :
    • citron = 0.2(Fait qq chose)
    • +super.Operation 
    • monComposant.Operation
    • lait = 0.3 (Fait qq chose)
    • +super.Operation 
    • monComposant.Operation
    • Deca = 0.5
    • Au retour Total = 1 €
    Component +Operation() ComposantConcret +Operation() Decorateur +Operation() -monComposant 1 Decorateur1 +Operation() Decorateur2 +Operation()
  • 153. Decorator : Participants
    • Les classes et/ou objets participant dans ce pattern sont:
      • Component (Boisson)   
        • D é finit l ’ interface pour les objets qui peuvent avoir des responsabilit é s ajout é es dynamiquement.
      • ConcreteComponent (deca)  
        • D é finit un objet auquel on peut rajouter des responsabilit é s.
      • Decorator (Ingredient)  
        • Maintient une r é f é rence sur le component et d é finie une interface conforme conforme à celle du component.
      • ConcreteDecorator (citron)  
        • Ajoute les responsabilit é s au composant.
  • 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. Decorator : Un mauvais exemple(1)
  • 156. Decorator : un mauvais exemple (2)
  • 157. Decorator : Exercice les soldats
  • 158. l ’Adaptateur : le contexte
    • 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.
    • Contexte : Ce pattern est particulièrement adapté lorsque les conditions suivantes sont remplies :
        • On veut utiliser une classe existante dont l'interface ne coïncide pas avec celle escomptée
        • On souhaite créer une classe qui puisse être accédée par des interfaces diverses
        • Récupération de vieilleries
        • Façade
  • 159. l ’Adaptateur : Uml et Exemple
  • 160. L'adaptateur : Participants
    • Les classes et/ou objets participant dans ce pattern sont:
      • Cible  
        • Définit ce qui est appelé par le client
      • Adapteur   
        • Fait le lien entre ce que veut le client et ce qui existe vraiment
      • Adapté   
        • C’est ce qui existe vraiment (récupération)
      • Client   
        • Ne connaît que l’interface de la cible.
  • 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. Composite : Le contexte & UML
    • On utilise le Composite lorsque on veut :
    • Représenter une hiérarchie d'objets
    • Ignorer la différence entre un composant simple et un composant
      • en contenant d'autres (interface uniforme)
    Comparer avec le décorateur
  • 163. Composite : Participants
      • Component   (Equipement)
        • Déclare l’interface pour les objets de la composition.
      • Leaf   (Peripherique)
        • Représente les objets feuilles (sans enfants) de la composition.
        • Définit le comportement de ces objets.
      • Composite   (Container)
        • Définit le comportement des objets ayant des enfants.
        • Range, stocke les composants enfants
      • Client   (pg main)
        • Manipule les objets comme un seul en s’appuyant sur l’interface du component.
      • Utilisation :
      • Fabriquer l'objet (Configurer)
      • Le client peut alors appeler Operation () sur l'objet global.
      • L'objet global est un composite (ou une feuille) particulier qui prmet de retrouver
        • l'ensemble du composite
  • 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. Composite : Solution le prix d'un ordi
  • 166. Façade : UML
  • 167. La Façade : le contexte
    • Problème :
      • La conception objet implique la décomposition de chaque système complexe en collection d’objets collaborant.
      • On veut limiter le couplage des utilisateurs du système avec les éléments de cette décomposition.
      • On veut garder la possibilité pour certains client de manipuler l’intérieur du système .
    • Solution : On créé un nouvel objet servant de façade à un type d’utilisateur donné et lui offrant des services de haut niveau.
  • 168. La Façade : les bénéfices
    • Conséquences :
      • Découplage d’une partie des clients avec le système considéré.
      • Réduction du nombre de classes (complexité) à prendre en compte pour ce client
      • Réduction des dépendances à la compilation
      • Certains langages (C++ avec les NameSpaces, java avec les packages) permettent de cacher une partie des classes d’un sous-système.
      • -> Encapsulation au niveau des systèmes
  • 169. Façade : Participants
    • Les classes et/ou objets participant dans ce pattern sont:
      • Façade   (Prêt)
        • Connaît les classes du sous système qui sont responsables de
        • chaque requête.
        • Transmet les requêtes aux classes adéquat.
      • Subsystem classes   (VerifApport, VerifSalaire, VerifCaution)
        • Implémentent les fonctionnalités du sous système.
        • Ne connaissent pas la façade
    Exemple : Transformation d'une liste en pile
  • 170. Façade : Exo
    • Apport est au moins de 10% du prêt
    • Prêt <= 250 fois le salaire
    • Caution >= à 50% du prêt
    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. Flyweight : Poids mouche :UML Utilisation : beaucoup de petits objets à se partager à plusieurs. Exemple : les caractères d'un document PluriGleton
  • 172. Poids mouche : Exemple : une forêt
    • Avantages :
      • Réduit le nb d'instances
      • Economise la mémoire
    • Rmq :tous les arbres doivent
    • être gérés de la même manière
  • 173. Bridge : UML Rmq : ressemble au state
  • 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. Les Design patterns Le GoF Création
    • Singleton : un et un seul objet visible par tous
    • Fabrication : créer un objet en fonction d'un paramètre
    • Fabrique abstraite : créer une famille d'objets tous cohérents
    • Monteur : construire un objet en différentes étapes
    • Prototype : permet de sp é cifier le type d'objets à cr é er en utilisant une
      • instance prototype. Le prototype sera copi é pour cr é er les nouveaux
      • objets.
  • 176.
    • Problème : Une classe nécessite de n’être instanciée qu’une seule fois dans une application
    • Contexte : Cette instance unique est utilisable à plusieurs endroits dans l ’application.
    • Solution : On va confier à la classe elle-même la responsabilité d’assurer l’unicité de son instance.
    Le singleton
  • 177. Le singleton uml
  • 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. 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. Fabrication : Problème de dépendance
    • La fabrication va permettre l'inversion des dépendances
    • on va encapsuler la création des objets dans une fabrique
    • on peut créer plusieurs objets, mais ils sont indépendants les uns
      • des autres
  • 181. Fabrication : exemple les pizzerias(1) L'usine Les produits
  • 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. Fabrication : le Design pattern
  • 184. Fabrication : Participants
    •   Les classes et/ou objets participant dans ce pattern sont:
      • Produit    (Page)
        • D é finie l ’ interface des objets cr éé s par la fabrication (Afficher)
      • ProduitConcret i    (Introduction,Plan,Conclusion,Dev)
        • implementent l ’ interface du produit (CreatePages)
      • Createur    (Document)
        • D é clare la m é thode &quot;Fabrication(String) : Produit&quot; qui rend un objet de type Produit.
      • CreateurConcret     (Report, Resume)
        • Surcharge la m é thode Fabrication pour rendre une instance du produit concret. C'est le code Beurgh!!!
        • Rmq :la m é thode peut ne pas avoir de param è tre, dans ce cas le code n'est pas beurgh.
  • 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. 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. Fabrication Abstraite : Structure <<instancie>> Application
  • 188. Fabrication Abstraite : Constituants
    • FabriqueAbstraite (Facultative)
      • Déclare une interface contenant les opérations de création d ’objets produits
      • abstraits
    • Fabrique concrète
      • Implémente les opérations de création d ’objets produits concrets
    • Produit Abstrait (Facultatif)
      • Déclare une interface pour un type d ’objet produit
    • Produit concret
      • Définit un objet produit qui doit être crée par la fabrication concrète
        • correspondante
      • Implémente l ’interface de ProduitAbstrait
    • Application
      • n’utilise que les interfaces déclarées par les classes FabriqueAbstraite et
        • ProduitAbstrait
  • 189. Fabrique Abstraite : Avantages et inconvénients
    • Isoler les classes concrètes
    • Faciliter la substitution d ’une famille de produits
    • Favoriser le maintien de la cohérence entre les objets
    • Gérer de nouveaux types de produits est complexe
    • Ne facilite pas la lisibilité
    Les trains FabriqueAbstraite CreerProduitA() CreerProduitB()
  • 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)
    • On utilise le buider lorsque :
    • L'algorithme pour créer un objet doit être indépendant des parties qui
      • le composent et de la façon de les assembler.
    • Le processus de construction permet différentes représentations de
      • l'objet construit.
  • 191. Builder : UML
  • 192. Builder : Participants
    • Les classes et/ou objets participant dans ce pattern sont:
      • Builder  (VehicleBuilder)
        • Spécifie une interface pour identifier les étapes de la création d’un produit.
      • ConcreteBuilder  (MotorCycleBuilder, CarBuilder, ScooterBuilder)
        • Construit et assemble les différentes parties d’un objet en implémentant l’interface du Builder.
        • Définit le produit final et permet de le retrouver.
      • Director  (Shop)
        • C’est le client (celui qui utilise le builder).
      • Product  (Vehicle)
        • Représente le ou les produits fabriqués
  • 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. 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. Prototype
    • Masque au client les complexités de la création de nouvelles instances
        • (new, clone, deserialisation, …)
    • Permet au client de générer des objets dont le type n’est pas connu.
    • Dans certaines circonstances, la copie d’un objet peut être plus efficace
      • que la création d’un objet (memberWiseClone du c#)
  • 196. Prototype : Participants
    • Les classes et/ou objets participant dans ce pattern sont:
      • Prototype 
        • Déclare une interface pour se cloner
      • ConcretePrototype
        • Implémente une opération pour se cloner
      • Client
        • Créé un nouvel objet en demandant au prototype de se cloner.
  • 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. DP : Exercice général(1) Abuser
  • 199. DP : Exercice général(2) Les canards
    • Traiter le cas des oies
    • Compter les coinscoins
    • Comment être sûr de compter tout le monde ?
    • Faire cancaner toute une troupe
    • Observer de temps en temps et en temps réel le couac de chaque canard
    Adaptateur Decorateur Fabrique abstraite Composite Observer
  • 200. Autres Patterns Les classes d'analyse Le raii
  • 201. Les classes d'analyse
    • Les trois axes d'une classe :
      • Boundery - Frontière - Vue
      • Contrôleur
      • Entity - Objets métier - modèle
    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. 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. (RAII) à la sauce Java (Finally)
  • 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. Patterns et architecture MVC FrameWork Organisation des packages Métriques
  • 206. Patterns et architecture MVC FrameWork Organisation des packages Métriques
  • 207. MVC V C M Vue 1 2 3 4 5
    • (Origine :SmallTalk-Xerox)
    • L'utilisateur a fait qq chose (bouton, menu, ….)
    • Le contrôleur prévient le modèle
    • Modification d'IHM (bouton non disponible, menu grisé, …)
    • Le modèle prévient la vue que qq chose est arrivé (changement d'état – Notify)
    • La vue demande des informations complémentaires
    • Cela permet d'avoir plusieurs vues, plusieurs modèles
  • 208. MVC : Design pattern composé V C M Composite Stratégie/etat Sujet Observer UpDate()
  • 209. MVC
  • 210. Framework : Introduction
    • Définition :
    • Un framework est une infrastructure logicielle qui facilite la conception des
    • applications par l'utilisation de bibliothèques de classes ou de générateurs
    • de programmes, soit dit en quelques mots : un cadre de développement.
    • Exemples:
    • Struts est un framework java d'interfaçage homme machine pour applications
      • web.
    • SWING est un framework java d'interfaçage homme machine pour une
      • application fenêtrée.
    • Les MFC sont un framework C++ d'interfaçage d'une application avec le
      • système d'exploitation windows.
    • la GTK est un framework C d'interfaçage homme machine avec une
      • application fenêtrée, conçu à l'origine pour les systèmes unix et porté
      • sur windows.
    • java est un framework, Dot.net aussi, Junit est un framework de test ….
  • 211. Framework : Utilisation
    • Il existe des frameworks de divers types, et ceux-ci sont complémentaires
    • un framework réunit l'ensemble des implémentations récurrentes de nos
      • développements. Les avantages en sont :
      • éviter de recoder encore et toujours les mêmes bouts de codes rébarbatifs,
      • agir en un point unique pour modifier l'ensemble du comportement
        • applicatif (Par exemple le &quot;look and feel&quot;) faisant profiter toutes les
        • applications des avancées du framework,
      • assurer la robustesse de ces parties du code (répétitives et essentielles).
    • Exemple Spring :
      • Java JEE est trop compliqué(pas d'héritage et de polymorphisme avec
      • Les EJB. 
        • Struts pour la présentation
        • Hibernate pour la persistance
  • 212. Composant
    • Un composant est formé avec:
    • Une interface définissant la structure objet nécessaire à la réalisation d'un
      • travail (ou plusieurs)
    • son implémentation.
    • Réunir un ensemble des classes et des interfaces ayant des comportements
    • agissant dans le même sens au sein de composants.
    • Les divers composants communiquent par le biais d'une Façade.
  • 213. Organisation des packages
  • 214. Organisation des packages
  • 215. Dépendances cycliques : Interface
    • L'application :
    • Crée un objet A
    • Crée un objet B
    • Présente B à A en tant
      • que FqqAble
    • Présente A à B en tant
      • que FqqAble
  • 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. 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. 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. Bibliographie
    • Valtech :
    • Management Agile
      • Christophe Addinquy (27mn)
      • David Gageot (17 mn)
    • Xp ca marche vraiment ? (régis Medina –18mn)
    • TV4IT :
    • Eric Groise
    • Michel Cara
    Vidéo Google : DP & Python : http://www.aleax.it/goo_pydp.pdf (2h)Alex Martelli
  • 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 Métriques 216 Bibliographie 219
  • 221. Junit 3.8->4
  • 222. Junit & DP
  • 223. Héritage versus composition Stack pile = new Stack(); pile.push(&quot;Bas de la pile&quot;); pile.push(&quot;Haut de la pile&quot;); pile.insertElementAt(&quot;Perdu&quot;, 0); while (!pile.empty()) { System.out.println(pile.pop()); } import java.util.logging.*; public class LoggedList extends ArrayList { private static final Logger LOG = Logger.getLogger(&quot;logged lists&quot;); public void add(E element) { LOG.info(&quot;Added element: &quot; + e.toString()); super.add(e); } public boolean addAll(Collection c) { for (E e : c) { LOG.info(&quot;Added element: &quot; + e.toString()); } super.addAll(c); }
  • 224. RMI : Securité
    • Depuis java2, utiliser la sécurité sur le SujetReel et le Client
    • Rajouter System.setSecurityManager(new RMISecurityManager());
    • Les lancer avec l'option :
      • java -Djava.security.policy= policy.all SujetReel
    grant { permission java.security.AllPermission; };
  • 225. RMI :UML rmiregistry (Sujet)Naming.lookup
  • 226. //SujetReel.java import java.rmi.*; import java.rmi.server.*; public class SujetReel extends UnicastRemoteObject implements Sujet { public SujetReel() throws RemoteException{super();}; public void Afficher(){System.out.println (&quot;Bonjour&quot;);} public static void main(String args[]) { try { System.setSecurityManager(new RMISecurityManager()); SujetReel leSujetReel = new SujetReel(); Naming.rebind(&quot;BonjourDeLoin&quot;, leSujetReel); }catch (Exception e) {System.out.println (&quot;excpt&quot;);} System.out.println(&quot;Le sujet est pret&quot;); } } //Sujet.java import java.rmi.*; public interface Sujet extends Remote { public void Afficher() throws RemoteException; }
  • 227. // Client.java import java.rmi.*; import java.rmi.server.*; import java.rmi.registry.*; public class Client { public static void main(String args[]) { System.setSecurityManager(new RMISecurityManager()); try{ Sujet monSujet = (Sujet)Naming.lookup(&quot;rmi://127.0.0.1/BonjourDeLoin&quot;); monSujet.Afficher(); }catch (Exception e) {System.out.println (&quot;excpt&quot;);} } }
  • 228. RMI :Mise en ouvre
  • 229. Automate-Tableau
  • 230. Refactoring-Métriques Avant Avant Après Après
  • 231. Abuser Metriques Sans DP Avec DP
  • 232. Les trains LocomotiveSurCoussin lr =new LocomotiveSurCoussin(); WagonSurRail wr =new WagonSurRail(); lr.Accrocher(wr); lr.Rouler(); FabriqueAbstraite f1 ; Locomotive lrail; Wagon wrail ; f1 = new FabriquePourRail(); lrail = f1.CreerLocomotive(); wrail = f1.CreerWagon(); lrail.Accrocher(wrail); lrail.Rouler(); f1 = new FabriquePourCoussin(); lrail = f1.CreerLocomotive(); wrail = f1.CreerWagon(); lrail.Accrocher(wrail); lrail.Rouler(); La loco sur coussin d'air vole La wagon sur rail roule La loco sur rail roule La wagon sur rail roule La loco sur coussin d'air vole La wagon sur coussin d'air vole
  • 233. Les trains
  • 234. Le Robot
  • 235.
  • 236. Le Robot : Composite Composite
  • 237.
  • 238.
  • 239. Métriques : Instability Afferent Coupling (CA) : Le nombre de classes hors d'une package qui dépendent d'une classe dans le package Efferent Coupling (CE) : Le nombre de classes dans un packages qui dépendent d'une classe d'un autre package. Instability (RMI) : CE / (CA + CE) : Ce nombre vous donnera l'instabilité de votre projet. C'est-à-dire les dépendances entre les paquets. CA = 0 CE = 2 RMI = 1 CA = 2 CE = 0 RMI = 0 CA = 2 CE = 1 RMI = 0,33