Design patterns : résumé

221 vues

Publié le

Un résumé des design patterns, diagrammes de classes, objectifs et résultats.

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

Aucun téléchargement
Vues
Nombre de vues
221
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
15
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • NOTE: Want a different image on this slide? Select the picture and delete it. Now click the Pictures icon in the placeholder to insert your own image.
  • Design patterns : résumé

    1. 1. DESIGN PATTERNS
    2. 2. Boubker ABERWAG Développeur Java/JEE IBM Client Innovation Center aberwagb@fr.ibm.com b_aberwag@yahoo.fr https://www.linkedin.com/in/boubkeraberwag http://www.viadeo.com/fr/profile/boubker.aberwag
    3. 3. ABSTRACT FACTORY
    4. 4. Abstract Factory  Fournir une interface pour créer des objets d'une même famille sans préciser leurs classes concrètes.  ¨Permet d'isoler l'appartenance à une famille de classes. Résultats Objectifs
    5. 5. Abstract Factory – Diagramme de classes
    6. 6. BUILDER
    7. 7. Builder • Séparer la construction d'un objet complexe de sa représentation.  Permet d'isoler des variations de représentations d'un objet. • Permettre d'obtenir des représentations différentes avec le même procédé de construction. Résultats Objectifs
    8. 8. Builder – Diagramme de classes
    9. 9. COMPOSITE
    10. 10. Composite • Organiser les objets en structure arborescente afin de représenter une hiérarchie  Permet d'isoler l'appartenance à un agrégat • Permettre à la partie cliente de manipuler un objet unique et un objet composé de la même manière Résultats Objectifs
    11. 11. Composite– Diagramme de classes
    12. 12. DECORATOR / WRAPPER
    13. 13. Decorator/Wrapper • Ajouter dynamiquement des responsabilités (non obligatoires) à un objet  Permet d'isoler les responsabilités d'un objet • Eviter de sous classer la classe pour rajouter ces responsabilités Résultats Objectifs
    14. 14. Decorator/Wrapper – Diagramme de classes
    15. 15. FACADE
    16. 16. Facade • Fournir une interface unique en remplacement d'un ensemble d'interfaces d'un sous-système  Permet d'isoler les fonctionnalités d'un sous-système utiles à la partie cliente • Définir une interface de haut niveau pour rendre le sous-système plus simple d'utilisation Résultats Objectifs
    17. 17. Facade– Diagramme de classes
    18. 18. MEDIATOR
    19. 19. Mediator • Gérer la transmission d'informations entre des objets interagissant entre eux  Permet d'isoler la communication entre des objets • Avoir un couplage faible entre les objets puisqu'ils n'ont pas de lien direct entre eux Résultats Objectifs • Pouvoir varier leur interaction indépendamment
    20. 20. Mediator– Diagramme de classes
    21. 21. STATE
    22. 22. State • Changer le comportement d'un objet selon son état interne  Permet d'isoler les algorithmes propres à chaque état d'un objet Résultats Objectifs
    23. 23. State– Diagramme de classes
    24. 24. STRATEGY
    25. 25. Strategy • Définir une famille d'algorithmes interchangeables  Permet d'isoler les algorithmes appartenant à une même famille d'algorithmes • Permettre de les changer indépendamment de la partie cliente Résultats Objectifs
    26. 26. Strategy– Diagramme de classes
    27. 27. TEMPLATE METHOD
    28. 28. Template Method • Définir le squelette d'un algorithme en déléguant certaines étapes à des sous- classes  Permet d'isoler les parties variables d'un algorithme Résultats Objectifs
    29. 29. Template Method – Diagramme de classes
    30. 30. COMMAND
    31. 31. Command • Encapsuler une requête sous la forme d'objet  Permet d'isoler une requête Résultats Objectifs • Paramétrer facilement des requêtes diverses • Permettre des opérations réversibles
    32. 32. Command– Diagramme de classes
    33. 33. OBSERVER
    34. 34. Observer • Prévenir des objets observateurs, enregistrés auprès d'un objet observé, d'un événement  Permet d'isoler un algorithme traitant un événement Résultats Objectifs
    35. 35. Observer– Diagramme de classes
    36. 36. PROXY
    37. 37. Proxy • Fournir un intermédiaire entre la partie cliente et un objet pour contrôler les accès à ce dernier  Permet d'isoler le comportement lors de l'accès à un objet Résultats Objectifs
    38. 38. Proxy– Diagramme de classes
    39. 39. BRIDGE
    40. 40. Bridge • Découpler l'abstraction d'un concept de son implémentation  Permet d'isoler le lien entre une couche de haut niveau et celle de bas niveau Résultats Objectifs • Permettre à l'abstraction et l'implémentation de varier indépendamment
    41. 41. Bridge– Diagramme de classes
    42. 42. ADAPTER
    43. 43. Adapter • Convertir l'interface d'une classe dans une autre interface comprise par la partie cliente  Permet d'isoler l'adaptation d'un sous-système Résultats Objectifs • Permettre à des classes de fonctionner ensemble, ce qui n'aurait pas été possible sinon (à cause de leurs interfaces incompatibles)
    44. 44. Adapter/héritage– Diagramme de classes
    45. 45. Adapter/Composition– Diagramme de classes

    ×