Les principaux Design Patterns

Transcription

Michaël Mrissa - [email protected]
Rappel: bonnes pratiques de programmation
Avant d’utiliser les design patterns. . .
Il faut déjà avoir des réflexes pour faire de la “bonne”
programmation
Utilisation d’UML (Unified Modeling Language)
Représentation abstraite orientée objet
Diagrammes de classes (objets)
Diagrammes de séquences (interactions entre objets)
Optimisation (Refactoring)
Savoir identifier les points communs dans le code
Un exemple: la connexion à la base de données
Séparation du code par bloc de fonctionnalié
Tester son code
Voir le framework Simpletest pour PHP
Notion de Design Pattern: introduction
Quelques informations générales
Notion introduite en 1977 par Christopher Alexander dans le
domaine de l’architecture
Description de problèmes récurrents et des solutions associées
Idée: Maximiser la réutilisation de connaissances existantes
pour faciliter la résolution de problèmes
Caractéristiques principales
Différent d’une librairie, solution abstraite (pas de code)
À personnaliser pour un problème donné
Définition: Design pattern
Technique abstraite de résolution d’un problème récurrent
Notion de Design Pattern: introduction
En trois mots
un nom: intention du code en un mot
un problème: domaine d’application
une solution: implantation, avantages/inconvénients
Notion d’inversion de contrôle...
3 Catégories de design patterns [GoF]
De création: Abstract Factory, Builder, Factory Method,
Prototype, Singleton
Structuraux: Adapter, Bridge, Composite, Decorator, Façade,
Flyweight, Proxy
Comportementaux: Chain of Responsibility, Command,
Interpreter, Iterator, Mediator, Memento, Observer, State,
Strategy, Template Method, Visitor
Dans le domaine informatique, LA référence de base
[GoF] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design
Patterns: Elements of Reusable Object-oriented Software (1995)
Le pattern “Abstract factory” en détails
Problème
On souhaite créer une instance d’une interface
mais quand on écrit le code
⇒ on ne sait pas de quel type concret l’instance va être
Ex: documents XML, bordures de fenêtre. . .
Solution
Fournit une interface pour la création d’objets d’une même
famille en ignorant la classe concrète d’implémentation
Figure: Abstract
Factory
Le pattern “Factory method” en détails
Problème
Le même que pour le pattern précédent
Solution
Mise en commun du code redondant, implémentation des
différents constructeurs des classes concrètes
Figure: Factory Method
Le pattern “Decorator” en détails
Problème:
Limitations de la notion d’héritage
⇒ Changement d’un comportement après instanciation?
⇒ Extensions multiples d’une même classe?
⇒ Ajout d’une capacité seulement à certaines instances de la
classe?
Solution:
Créer une classe apportant une réponse de fonctionnalité,
comme le décorator
Avantages
Empêche l’explosion des sous-classes
permet d’attribuer des capacités individuellement
dynamiquement et de manière transparente
Le pattern “Decorator” en détails
Figure: Decorator
Component (VisualComponent): interface commune aux objets associés aux
decorators
ConcreteComponent (TextView): l’objet auquel on attache les capacités du
decorator
Decorator: référence l’objet Component et définit l’interface des decorators
conforme à l’interface commune
ConcreteDecorator (BorderDecorator, ScrollDecorator): ajoute les capacités aux
ConcreteComponents
Le pattern “Composite” en détails
Problème
On souhaite créer des objets qui sont formés de plusieurs
autres objets
Ex: logiciel de dessin, ou de cuisine
Solution
On définit un objet composant qui est une interface pour tous
les objets formant la composition
On déclare une classe permettant de gérer les enfants (add,
remove, etc.)
Le pattern “Strategy” (détails vus en Génie Logiciel)
Problème
Plusieurs classes associées ont des comportements différents
On cache l’organisation des classes de l’extérieur ou on
propose un choix
Ex: sort (plusieurs algos)
Solution
On définit une super classes qui englobe les classes associées
Figure: Strategy
Le pattern “Adapter” (détails vus en Génie Logiciel)
Problème
On veut rendre plusieurs classes existantes conformes à la
même interface
Il est coûteux de les redéfinir leurs interfaces pour les adapter à
une interface commune
Solution
par héritage ou par composition
l’adaptateur transmet les requêtes client de l’interface vers
l’objet adapté
implique que les fonctions manquantes soient implémentées
pour répondre à l’interface
Le pattern “Proxy” (détails vus en Génie Logiciel)
Problème
On veut référencer un objet en ajoutant des fonctionnalités
Par exemple, de chargement, de sécurité (contrôle d’accès), de
persistence, etc.
Solution
On utilise un proxy comme une copie de l’objet d’origine
On accède au proxy, celui-ci effectue les opérations
dynamiquement selon les demandes du client
Ex: chargement de document avec images “lourdes”
Figure: Proxy
Le pattern “Observer” (détails vus en Génie Logiciel)
Problème ⇒ Identifier lorsqu’un objet change d’état
Solution
Une ou plusieurs classes “Observer” représentant les “clients”
Une classe “Observable” représentant l’objet surveillé
Un système d’inscription pour être notifié des changements
Figure: Observer
Le pattern “MVC” en détails
Problème
Séparation des problématiques pour les architectures Web
Solution
Model: Accès BD, Controller: logique métier, View: formatage
du code
Plus qu’un simple pattern, se situe au niveau architectural
Figure: Le pattern MVC
Conclusion
Beaucoup de design patterns
Plutôt orienté objet
⇒ mais tout à fait applicable en dehors du paradigme objet
Cohérence générale
“Contournement” des limitations de l’OOP
Notion d’architecture (!!) dans le code

Les principaux Design Patterns

Transcription

Documents pareils

Le Département «TC-Commercialisation des Systèmes, Solutions et

Technico-commercial en Produits et Services Industriels

UNIVERSITE LYON 1 (CLAUDE BERNARD) Référence GALAXIE

Diplôme D`Université

Management des organisations - MEDEF Lyon

Profil des étudiants - IUT de Rambouillet

grille éval soutenance stage

E-business dans les PME (EBUS)

COMMUNIQUE DE PRESSE 24/07/2015 Le Football Féminin d`Issy

15276 Tesselations Glassine Paper Guide

Un Modèle de Mémoire Associative dans le Cerveau