• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Design Pattern introduction
 

Design Pattern introduction

on

  • 1,282 views

Présentation à la nAcademy (Mai 2011) : Design Patterns Introduction par Cédric Mourouvin

Présentation à la nAcademy (Mai 2011) : Design Patterns Introduction par Cédric Mourouvin

Statistics

Views

Total Views
1,282
Views on SlideShare
1,278
Embed Views
4

Actions

Likes
0
Downloads
21
Comments
0

1 Embed 4

http://www.neuros.fr 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Design Pattern introduction Design Pattern introduction Presentation Transcript

    • nAccademy Design Patterns IntroductionPrésentation par Frédéric Salembier Le 5 mai 2011
    • Plan Qu’est ce qu’un design pattern ? Comment les classer ? Le singleton La factory
    • Qu’est ce qu’un design pattern ? Définition ◦ Solution empirique pour résoudre un problème identifié et partagé ◦ Equivalent à une bibliothèque de coups d’un logiciel d’échecs Mise en place ◦ Premiers sont apparus fin années 70 ◦ Un domaine très vaste ◦ Il s’applique au monde objet ◦ Indépendant du langage Attention ce n’est pas une science ◦ Le principe est de plaquer une méthode connu pour résoudre un problème ◦ La difficulté est de reconnaitre les cas d’utilisations ◦ Le risque est d’en mettre partout
    • Les trois familles Patterns créateurs ◦ Utilisés pour construire des objets découplés du système de mise en œuvre. ◦ Exemples : Factory, Builder, Singleton Patterns structurels ◦ Utilisés pour former des structures objet de grande taille entre de nombreux objets disparates. ◦ Exemples : Proxy, Decorateur, Facade Patterns comportementaux ◦ Permettent de gérer des algorithmes ou relations entre objets indépendamment de l’objet sur lequel ils s’appuient. ◦ Exemples : Iterator, Strategy, Observer
    • Singleton : présentation Avantages pour l’architecte ◦ Garantir qu’une classe ne possède qu’une seule instance Avantages pour le développeur ◦ Avoir un point d’accès global à l’instance Utilisations ◦ Accès de n’importe où à un système de log ◦ Accès à un lecteur de configurations pour ne pas rouvrir à chaque fois le fichier
    • Singleton : mise en place  Principes ◦ Une auto référence privée dans l’objet ◦ Un constructeur privé ◦ Une méthode public (getter) d’accès à l’instance qui teste l’initialisation  Code java// Classe basée sur le pattern Singleton qui permet la journalisation de lapplication.public class Journalisation{ private static Journalisation uniqueInstance;// Stockage de lunique instance de cette classe. private Integer nbAppel; // Entier représentant le nb dappel. // Constructeur en privé (donc inaccessible à lextérieur de la classe). private Journalisation() { this.nbAppel = new Integer(0); } // Méthode statique qui sert de pseudo-constructeur public static Journalisation getInstance() { if (uniqueInstance == null) { uniqueInstance = new Journalisation(); } return uniqueInstance; } public void ajouterAppel(String log) { this.nbAppel++; } public String getNbAppel() { return this.nbAppel; }}
    • Singleton : exercice Dans l’exemple précédent une notion fondamentale à été oubliée, laquelle ?
    • Factory : présentation Avantages pour l’architecte ◦ Isolation du code métier ◦ Factorisation des algorithmes Avantages pour le développeur ◦ Abstraction des méthodes : principe de la boite noire ◦ Utilisation de méthodes générique
    • Factory : exempleCalculateurFactory+ getTarificateur(contexte){ // algo de détermination du calculateur // renvoie d’une instance de la classeconcrète choisie} Calculateur + getTarif(params); << instantiate >> CalculateurAuto CalculateurMRH CalculateurSante + getTarif(params) + getTarif(params) + getTarif(params) { { { // code d’implémentation // code d’implémentation // code d’implémentation } } }
    • Factory : utilisation  Schéma pour la formule Calculateur +List<String> getFormules();CalculateurAuto CalculateurMRH CalculateurSante CalculateurScolaire+List<String> getFormules() +List<String> getFormules(){ { // implémentation // implémentation} }  Exemple d’algo de formules Pour le calculateurAuto : return {‘Confort’, ‘Maxi’} Pour le CalculateurMRH return {‘Sérénité’, ‘Essentiel’, ‘Complete’}
    • Factory : exercices (plus loin dans la généricité) 1/ Comment gérer des contextes différents dans la même factory ? 2/ Implémentez cet algorithme :Voici les fractionnements proposés pour les produitsAuto classique -> [‘A’, ‘T’, ‘M’]Auto bon conducteur -> [‘A’, ‘T’, ‘M’]Auto jeune -> [‘A’, ‘S’, ‘T’, ‘M’]Auto malussé -> [‘U’]
    • Factory : exercice 1 Généralisation du contexte :ContexteBean contexte = new ContexteBean(client, vehicule, conducteurs, contrat);Calculateur tarification = CalculateurFactory.getTarificateur(codeOperation);DevisResultBean devisResult = (DevisResultT9Bean) tarification.getTarif(contexte); CalculateurBean CalculateurBeanContexte CalculateurBeanAuto CalculateurBeanTarifResult - int idPolice; - Client cli; - String Formule; - String login; - Vehicule veh; - String fractionnement; - String codeOperation; - <Conducteur> conducts; - Float prime; - String login; - Float taxes; // les getters et setters // les getters et setters // les getters et setters
    • Factory : exercice 2  ImplémentationProduitAlgo implements ProduitAlgoInterface{ public List<String> getFractionnements() { return {‘A’, ‘T’, ‘M’}; }}ProduitAlgoClassique extends ProduitAlgo{ ø}ProduitAlgoMalusse extends ProduitAlgo{ public List<String> getFractionnements() { return {‘U’}; }}ProduitAlgoJeune extends ProduitAlgo{ public List<String> getFractionnements() { List<String> list = super.getFractionnements(); list.add(‘T’); return list; }}
    • Conclusion Souvent utilisés sans même le savoir Buts ◦ Simplifier le code ◦ Le rendre plus efficace et robuste ◦ Permettre un langage commun entre développeurs Gain ◦ obtenir de la généricité pour pérenniser les développements Attention ◦ ce ne sont pas des solutions miracles ◦ aux abus, tout n’est pas design pattern Aller plus loin avec le wiki neuros