11. 1- Quèsaco
(définition)
Arrangement caractéristique de modules reconnus
comme bonne pratique en réponse à un problème de
conception d’un logiciel.
(Wikipédia, 2015)
Chaque patron décrit un problème qui se manifeste
constamment dans notre environnement, et décrit le
cœur de la solution à ce problème, d’une façon telle que
l‘on puisse réutiliser cette solution des millions de fois,
sans jamais le faire deux fois de la même manière.
12. 1- Quèsaco
(définition)
Arrangement caractéristique de modules reconnus
comme bonne pratique en réponse à un problème de
conception d’un logiciel.
(Wikipédia, 2015)
Chaque patron décrit un problème qui se manifeste
constamment dans notre environnement, et décrit le
cœur de la solution à ce problème, d’une façon telle que
l‘on puisse réutiliser cette solution des millions de fois,
sans jamais le faire deux fois de la même manière.
(Christopher Alexander, 1977)
13. 1- Quèsaco
(définition)
Arrangement caractéristique de modules reconnus
comme bonne pratique en réponse à un problème de
conception d’un logiciel.
(Wikipédia, 2015)
Chaque patron décrit un problème qui se manifeste
constamment dans notre environnement, et décrit le
cœur de la solution à ce problème, d’une façon telle que
l‘on puisse réutiliser cette solution des millions de fois,
sans jamais le faire deux fois de la même manière.
(Christopher Alexander, 1977)
Les patrons offrent la possibilité de capitaliser un savoir
précieux né du savoir-faire d’experts.
14. 1- Quèsaco
(définition)
Arrangement caractéristique de modules reconnus
comme bonne pratique en réponse à un problème de
conception d’un logiciel.
(Wikipédia, 2015)
Chaque patron décrit un problème qui se manifeste
constamment dans notre environnement, et décrit le
cœur de la solution à ce problème, d’une façon telle que
l‘on puisse réutiliser cette solution des millions de fois,
sans jamais le faire deux fois de la même manière.
(Christopher Alexander, 1977)
Les patrons offrent la possibilité de capitaliser un savoir
précieux né du savoir-faire d’experts.
(Bushman, 1996)
16. 1- Quèsaco
(Intérêts)
Les Design Pattern servent à documenter des bonnes
pratiques basées sur l’expérience.
Ils proposent des solutions à des problèmes qui peuvent
être difficilement résolus par un seul composant
(Exemple: Le pattern Observer : sujet et observateur)
17. 1- Quèsaco
(Intérêts)
Les Design Pattern servent à documenter des bonnes
pratiques basées sur l’expérience.
NB: En programmation informatique, les Design Pattern
peuvent être utilisés avant, pendant, ou après le travail de
programmation.
Ils proposent des solutions à des problèmes qui peuvent
être difficilement résolus par un seul composant
(Exemple: Le pattern Observer : sujet et observateur)
21. 1- Quèsaco
(Formalismes)
Nom
Description du problème à résoudre
Description de la solution (Appelée, Design Pattern)
Conséquences
22. 1- Quèsaco
(Formalismes)
Nom
Description du problème à résoudre
Description de la solution (Appelée, Design Pattern)
Conséquences
NB: Ce formalisme aide surtout à mieux comprendre
l’utilisation et la logique interne […]
23. 1- Quèsaco
(Les Familles)
Ils existe de nombreux Design Pattern, tous aussi
important les uns que les autres. Cependant, ont les
regroupes sous trois grandes familles.
24. 1- Quèsaco
(Les Familles)
Ils existe de nombreux Design Pattern, tous aussi
important les uns que les autres. Cependant, ont les
regroupes sous trois grandes familles.
Modèles de création
Modèles de structuration
Modèles de comportement
26. 2- Les modèles
de créations
Un Design Pattern de création permet de résoudre les
problèmes liées à la création et la configuration d’objets.
27. 2- Les modèles
de créations
Un Design Pattern de création permet de résoudre les
problèmes liées à la création et la configuration d’objets.
Ils aident le développeur à réaliser des systèmes
indépendant de comment ses objets sont créés,
composés et représentés.
28. 2- Les modèles
de créations
Un Design Pattern de création permet de résoudre les
problèmes liées à la création et la configuration d’objets.
Ils aident le développeur à réaliser des systèmes
indépendant de comment ses objets sont créés,
composés et représentés.
(Thème récurrent 1)
29. 2- Les modèles
de créations
Un Design Pattern de création permet de résoudre les
problèmes liées à la création et la configuration d’objets.
Ils aident le développeur à réaliser des systèmes
indépendant de comment ses objets sont créés,
composés et représentés.
(Thème récurrent 1)
Ils encapsulent tous, les connaissances à propos de quelle
classe concrète le système utilise.
30. 2- Les modèles
de créations
Un Design Pattern de création permet de résoudre les
problèmes liées à la création et la configuration d’objets.
Ils aident le développeur à réaliser des systèmes
indépendant de comment ses objets sont créés,
composés et représentés.
(Thème récurrent 1)
Ils encapsulent tous, les connaissances à propos de quelle
classe concrète le système utilise.
(Thème récurrent 2)
31. 2- Les modèles
de créations
Un Design Pattern de création permet de résoudre les
problèmes liées à la création et la configuration d’objets.
Ils aident le développeur à réaliser des systèmes
indépendant de comment ses objets sont créés,
composés et représentés.
(Thème récurrent 1)
Ils encapsulent tous, les connaissances à propos de quelle
classe concrète le système utilise.
(Thème récurrent 2)
Ils masquent comment les instances des classes concrètes
sont crées et mises ensembles.
32. 2- Les modèles
de créations
Les principaux Design Pattern de création sont
33. 2- Les modèles
de créations
Les principaux Design Pattern de création sont
Factory
34. 2- Les modèles
de créations
Les principaux Design Pattern de création sont
Factory
Abstract Factory
35. 2- Les modèles
de créations
Les principaux Design Pattern de création sont
Factory
Abstract Factory
Builder
36. 2- Les modèles
de créations
Les principaux Design Pattern de création sont
Factory
Abstract Factory
Builder
Singleton
37. 2- Les modèles
de créations
Les principaux Design Pattern de création sont
Factory
Abstract Factory
Builder
Singleton
Prototype
39. 3- Les modèles
de
structuration
Un Design Pattern de structuration décrivent comment
les classes et les objets sont composés pour former une
large structure.
40. 3- Les modèles
de
structuration
Un Design Pattern de structuration décrivent comment
les classes et les objets sont composés pour former une
large structure.
Ils utilisent l’héritage pour composer des interfaces ou
des implémentations.
50. Un Design Pattern de comportement sont relatifs aux
algorithmes et à l’assignement des responsabilités entre
objets.
4- Les modèles
de
comportement
51. Un Design Pattern de comportement sont relatifs aux
algorithmes et à l’assignement des responsabilités entre
objets.
Il ne décrit pas juste le modèle des objets et des classes
mais aussi comment ils communiquent entre eux.4- Les modèles
de
comportement
52. Un Design Pattern de comportement sont relatifs aux
algorithmes et à l’assignement des responsabilités entre
objets.
Il ne décrit pas juste le modèle des objets et des classes
mais aussi comment ils communiquent entre eux.
Il utilise l’héritage pour distribuer des comportement
entre les classes.
4- Les modèles
de
comportement
53. Les principaux Design Pattern de comportement sont
Chain of Responsability
4- Les modèles
de
comportement
54. Les principaux Design Pattern de comportement sont
Chain of Responsability
Command4- Les modèles
de
comportement
55. Les principaux Design Pattern de comportement sont
Chain of Responsability
Command
Iterator
4- Les modèles
de
comportement
56. Les principaux Design Pattern de comportement sont
Chain of Responsability
Command
Iterator
Mediator
4- Les modèles
de
comportement
57. Les principaux Design Pattern de comportement sont
Chain of Responsability
Command
Iterator
Mediator
Memento
4- Les modèles
de
comportement
58. Les principaux Design Pattern de comportement sont
Chain of Responsability
Command
Iterator
Mediator
Memento
Observer
4- Les modèles
de
comportement
59. Les principaux Design Pattern de comportement sont
Chain of Responsability
Command
Iterator
Mediator
Memento
Observer
State
4- Les modèles
de
comportement
64. Les Design Pattern ou Patron de
Conception sont des solutions à des
problèmes de Génie Logiciel issues de
l’expérience d’experts.
+
65. Les Design Pattern ou Patron de
Conception sont des solutions à des
problèmes de Génie Logiciel issues de
l’expérience d’experts.
+
Ils permettent d’adopter de bonne
pratique et de concevoir des logiciels
flexibles.
66. Les Design Pattern ou Patron de
Conception sont des solutions à des
problèmes de Génie Logiciel issues de
l’expérience d’experts.
+
Ils permettent d’adopter de bonne
pratique et de concevoir des logiciels
flexibles.
Ceux sont des solutions 100% fiables
67. Les Design Pattern ou Patron de
Conception sont des solutions à des
problèmes de Génie Logiciel issues de
l’expérience d’experts.
+ -
Ils permettent d’adopter de bonne
pratique et de concevoir des logiciels
flexibles.
Ceux sont des solutions 100% fiables
68. Les Design Pattern ou Patron de
Conception sont des solutions à des
problèmes de Génie Logiciel issues de
l’expérience d’experts.
+ -
Ils permettent d’adopter de bonne
pratique et de concevoir des logiciels
flexibles.
Ceux sont des solutions 100% fiables
Une mauvaise utilisation des Design
Pattern est de vouloir tous les utiliser
dans un même logiciel.
69. Les Design Pattern ou Patron de
Conception sont des solutions à des
problèmes de Génie Logiciel issues de
l’expérience d’experts.
+ -
Ils permettent d’adopter de bonne
pratique et de concevoir des logiciels
flexibles.
Ceux sont des solutions 100% fiables
Une mauvaise utilisation des Design
Pattern est de vouloir tous les utiliser
dans un même logiciel.
Ils faut s’assurer de la nécessité d’un
Design Pattern avant de l’utiliser au risque
de rendre le code moins lisible.
Notes de l'éditeur
Christopher Alexander (Précurseur) parlais de construction de bâtiments.
Christopher Alexander (Précurseur) parlais de construction de bâtiments.
Christopher Alexander (Précurseur) parlais de construction de bâtiments.
Christopher Alexander (Précurseur) parlais de construction de bâtiments.
Christopher Alexander (Précurseur) parlais de construction de bâtiments.
Christopher Alexander (Précurseur) parlais de construction de bâtiments.
Avant: Le programmeur utilise le patron comme guide lors de l’écriture du code source.
Après: Il servira comme exemple pour relier différents modules de ce code source déjà écrits.
Avant: Le programmeur utilise le patron comme guide lors de l’écriture du code source.
Après: Il servira comme exemple pour relier différents modules de ce code source déjà écrits.
Avant: Le programmeur utilise le patron comme guide lors de l’écriture du code source.
Après: Il servira comme exemple pour relier différents modules de ce code source déjà écrits.