19. DESIGN
PATTERN:
• Recettes prêtes pour des problèmes de
programmation orienté objet (Qui
répondent aux principes déjà discutés).
• Reutilisation de code : pas de
reinvention de la rue.
• Assurer un langage commun.
• Applicable à un contexte.
21. 3 CATÉGORIES DE
PATTERNS
• Créationnel.
• Instanciation d’objets.
• Structurel.
• Structures larges
d’objets et de classes.
• Comportemental.
• Interaction et distribution
de responsabilités.
22. DESIGN PATTERNS
CRÉATIONNELS:
• Factory : Créer des objets sans exposer la logique
d’instanciation.
• Abstract Factory : Encapsulation d’une famille de factories
qui produit des familles d’objets.
• Builder : Séparation de la construction d’un objet complexe
de sa représentation.
• Singleton : Assurer qu’une seule instance d’une classe
existe tout en fournissant une seule méthode pour accéder
cette instance.
• Prototype : Créer une instance initialisée pour clonage.
• Object Pool : Réutilisation et partage d’objets coûteux à
créer.
23. DESIGN PATTERNS
STRUCTURELS:
• Adapter : Adapter une interface à une autre incompatible.
• Bridge : Séparer l’abstraction de l’implémentation.
• Composite : Composer les objets dans une structure
d’arbres.
• Decorator : Ajouter de nouveaux comportements de façon
dynamique ou statiques.
• Facade : Simplifier l’utilisation en définissant une interface
de haut niveau.
• Flyweight : Partager une partie des états d’objets.
• Proxy : Créer une référence à un autre objet (pouvant être
distant).
24. DESIGN PATTERNS
COMPORTEMENTAUX:
• Chaine de Responsabilité : Définir une méthode pour faire
passer une requête à travers une chaine d’objets.
• Commande : Encapsuler une requête type commande dans
un objet.
• Interpreter : Spécifier comment interpréter un langage.
• Iterator : Accéder aux éléments d’une conteneur.
• Mediator : Centralisation du mécanisme de communication
entre les objets.
• Memento : Permettre la récupération des états antérieurs.
• Observer : Notifier plusieurs objets du changement d’état
d’un objet particulier.
25. DESIGN PATTERNS
COMPORTEMENTAUX:
• State : Encapsuler différents comportements pour la même
routine en se basant sur l’état de l’objet.
• Strategy : Séparer l’implémentation de l’algorithme de son
utilisation.
• Template Method : Définir le squelette d’un algorithme
dans une opération, différer certaines étapes dans les sous-
classes.
• Visitor : Séparer un algorithme de la structure d’objet sur
lequel il opère.
• Null Object : Définir un objet avec un comportement neutre.
26. TOUT CELA EST BIEN, MAIS
CE N’EST QUE LE DÉBUT DE
L’HISTOIRE……
28. LE DESIGN EMERGEANT:
• On ne peut pas prévoir les design patterns à utiliser, on les
découvre.
• Les patterns présentés sont de nature technique, alors qu’il
existe des patterns du domaine.
• Le logiciel en lui-même change d’objectif et de structure, de
fait de plusieurs facteurs de l’environnement.
29. PRÉPARER L’ÉMERGENCE DU
DESIGN:
• Le code doit être expressif.
• Les responsables de l’architecture doivent coder eux aussi.
• Séparer l’architecture (difficile à changer) du design (assez
flexible pour être changé).
• Les décisions définitives de la conception doivent être faits
le plus tard possible.
• Choisissez un framework qui est découplé et qui respecte
les principes de la bonne conception.
• Comprendre le domaine d’étude.
• Adopter le TDD (Un programme difficile à tester implique à
un certain niveau une mauvaise conception).
30. Extracted vs. preemptive frameworks
The best frameworks tend to be those extracted from working code rather than
preemptively designed. Someone sitting down to design a framework must anticipate all
the ways developers might want to use it. The framework ends up including lots of
features, with a high chance that any given user won't use all of them. But you still must
take the unused features of your chosen framework into account, because they add to your
applications' accidental complexity; this could mean doing something as simple as making
extra entries in a configuration document, or as intrusive as changing the way you'd like to
implement a feature. Preemptive frameworks tend to be giant buckets of features, with
other (unanticipated) features left out. JavaServer Faces (JSF) is a classic example of a
preemptive framework. One of its cool features is the ability to plug in different rendering
pipelines, in case you want to emit a format other than HTML. Although this feature is
used rarely, all JSF users must understand its impact on a JSF request's life cycle.
Frameworks that grow from working applications tend to offer a more pragmatic set of
features, because they address the actual problems someone faced when writing an
application.
Extracted frameworks tend to have fewer extraneous features. Contrast a preemptive
framework like JSF with an extracted framework like Ruby on Rails, which has grown
from actual usage.
32. • Les Designs Patterns répondent à des problématiques
purement techniques, et peuvent éventuellement
s’appliquer à une conception d’un domaine d’étude (Finance,
Sport, Recrutement, etc. ou Conception Orientée Domaine).
• Les Patterns du domaine reflètent des concepts profondes
émergeant du domaine.
PATTERN DU DOMAINE :
35. • Language réduit pour définir et générer un modèle.
• S’applique dans un cadre particulier du domaine.
• Communique plus clairement l’objectif d’une partie du
système.
• Améliore la communication avec les experts du domaine.
• Constitue un modèle alternative à une conception purement
orientée objet.
• Exemples :
• Grammaire d’un langage de programmation.
• Automate à été fini.
DOMAIN SPECIFIC LANGUAGE :