Les principaux Design Patterns. Michaël Mrissa -

Transcription

1

2 Rappel: bonnes pratiques de programmation Avant d utiliser les design patterns... Il faut déjà avoir des réflexes pour faire de la bonne programmation Utilisation d UML (Unified Modeling Language) Représentation abstraite orientée objet Diagrammes de classes (objets) Diagrammes de séquences (interactions entre objets) Optimisation (Refactoring) Savoir identifier les points communs dans le code Un exemple: la connexion à la base de données Séparation du code par bloc de fonctionnalié Tester son code Voir le framework Simpletest pour PHP

3 Notion de Design Pattern: introduction Quelques informations générales Notion introduite en 1977 par Christopher Alexander dans le domaine de l architecture Description de problèmes récurrents et des solutions associées Idée: Maximiser la réutilisation de connaissances existantes pour faciliter la résolution de problèmes Caractéristiques principales Différent d une librairie, solution abstraite (pas de code) À personnaliser pour un problème donné Définition: Design pattern Technique abstraite de résolution d un problème récurrent

4 Notion de Design Pattern: introduction En trois mots un nom: intention du code en un mot un problème: domaine d application une solution: implantation, avantages/inconvénients Notion d inversion de contrôle... 3 Catégories de design patterns [GoF] De création: Abstract Factory, Builder, Factory Method, Prototype, Singleton Structuraux: Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy Comportementaux: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor Dans le domaine informatique, LA référence de base [GoF] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns: Elements of Reusable Object-oriented Software (1995)

5 Le pattern Abstract factory en détails Problème On souhaite créer une instance d une interface mais quand on écrit le code on ne sait pas de quel type concret l instance va être Ex: documents XML, bordures de fenêtre... Fournit une interface pour la création d objets d une même famille en ignorant la classe concrète d implémentation Figure: Abstract Factory

6 Le pattern Factory method en détails Problème Le même que pour le pattern précédent Mise en commun du code redondant, implémentation des différents constructeurs des classes concrètes Figure: Factory Method

7 Le pattern Decorator en détails Problème: Limitations de la notion d héritage Changement d un comportement après instanciation? Extensions multiples d une même classe? Ajout d une capacité seulement à certaines instances de la classe? : Créer une classe apportant une réponse de fonctionnalité, comme le décorator Avantages Empêche l explosion des sous-classes permet d attribuer des capacités individuellement dynamiquement et de manière transparente

8 Le pattern Decorator en détails Figure: Decorator Component (VisualComponent): interface commune aux objets associés aux decorators ConcreteComponent (TextView): l objet auquel on attache les capacités du decorator Decorator: référence l objet Component et définit l interface des decorators conforme à l interface commune ConcreteDecorator (BorderDecorator, ScrollDecorator): ajoute les capacités aux ConcreteComponents

9 Le pattern Composite en détails Problème On souhaite créer des objets qui sont formés de plusieurs autres objets Ex: logiciel de dessin, ou de cuisine On définit un objet composant qui est une interface pour tous les objets formant la composition On déclare une classe permettant de gérer les enfants (add, remove, etc.)

10 Le pattern Strategy (détails vus en Génie Logiciel) Problème Plusieurs classes associées ont des comportements différents On cache l organisation des classes de l extérieur ou on propose un choix Ex: sort (plusieurs algos) On définit une super classes qui englobe les classes associées Figure: Strategy

11 Le pattern Adapter (détails vus en Génie Logiciel) Problème On veut rendre plusieurs classes existantes conformes à la même interface Il est coûteux de les redéfinir leurs interfaces pour les adapter à une interface commune par héritage ou par composition l adaptateur transmet les requêtes client de l interface vers l objet adapté implique que les fonctions manquantes soient implémentées pour répondre à l interface

12 Le pattern Proxy (détails vus en Génie Logiciel) Problème On veut référencer un objet en ajoutant des fonctionnalités Par exemple, de chargement, de sécurité (contrôle d accès), de persistence, etc. On utilise un proxy comme une copie de l objet d origine On accède au proxy, celui-ci effectue les opérations dynamiquement selon les demandes du client Ex: chargement de document avec images lourdes Figure: Proxy

13 Le pattern Observer (détails vus en Génie Logiciel) Problème Identifier lorsqu un objet change d état Une ou plusieurs classes Observer représentant les clients Une classe Observable représentant l objet surveillé Un système d inscription pour être notifié des changements Figure: Observer

14 Le pattern MVC en détails Problème Séparation des problématiques pour les architectures Web Model: Accès BD, Controller: logique métier, View: formatage du code Plus qu un simple pattern, se situe au niveau architectural Figure: Le pattern MVC

15 Conclusion Beaucoup de design patterns Plutôt orienté objet mais tout à fait applicable en dehors du paradigme objet Cohérence générale Contournement des limitations de l OOP Notion d architecture (!!) dans le code