Réutilisation conceptuelle
Motivations (1/2)
* Concevoir un système objet est difficile
* Beaucoup d'aspects à considérer
* Décomposition du système
* Factorisation du code
* Relations entre les composants
* Héritage, association, agrégation / composition, délégation
* Prévoir et intégrer dès la conception
* Réutilisation du code
* Evolutions / extensions possibles
==> Introduire de la réutilisabilité
Motivations (2/2)
* Bénéficier des bonnes pratiques de l'industrie
* Minimiser les risques dans la phase de développement
* Se référer à l'existant
* Reprendre des solutions éprouvées
* Permettre une réutilisation
* Au niveau implémentation
* Mêmes structures de données / algorithmes
==> Bibliothèques logicielles
* Au niveau conception
* Mêmes organisations des composants
==> Patrons de conception (ou "design patterns")
Réutilisation: niveaux d'abstraction
* A chaque nouvelle expérience, on peut réutiliser
* Sans outil particulier: réutilisation niveau par niveau
Réutilisation: analyse de domaine
* Profiter de plusieurs expériences du même domaine
Réutilisation: patrons de conception
* Problèmes de conception récurrents ==> Patrons de conception
* Solutions génériques réutilisables au niveau conception
Réutilisation: cadriciel (framework)
* Réutilisation au niveau implémentation ==> Bibliothèques logicielles
* Cadriciel = composants réutilisables (conception + implémentation)
Patrons de conception
* Définition
* Patron de conception = design pattern
* Un design pattern traite un problème de conception récurrent
* Il apporte une solution générale, indépendante du contexte
* En clair
* Description de l'organisation de classes et d'instances en interaction pour résoudre un problème de conception
* Solution générique de conception
* Doit être "élégante" et réutilisable
* Doit être testée et validée dans l'industrie logicielle
* Doit viser un gain en terme de génie logiciel
* Doit être indépendante du contexte
Référencement des design patterns (1/2)
* Tentatives de référencement des patrons de conception
* Livre fondateur (23 patrons)
* Design Patterns: Elements of Reusable Object-Oriented Software
* Gamma, Helm, Johnson, Vlissides
* Surnommés le "Gang of Four" (GoF)
* Addison-Wesley, 1994
* Patrons en environnement distribué (17 patrons)
* Pattern-Oriented Software Architecture:
Patterns for Concurrent and Networked Objects
* Schmidt, Stal, Rohnert, Buschmann
* Wiley, 2000
Référencement des design patterns (2/2)
* Mais ce ne sont pas les seuls patrons
* Patron MVC (Modèle-Vue-Contrôleur)
* Patrons GRASP
* Proposés par Craig Larman
* Plus conceptuels
* Communauté active
* De nouveaux patrons proposés régulièrement
* Démocratique: adoptés si utilisés et génériques
* Exemples
* Reversible Command (Undo)
* Lazy Initialization
* Liste plus exhaustive sur Wikipedia
* Dans sa version anglaise
Patrons de conception du GoF (1/3)
* Quatre éléments principaux définissent un patron
* Objectif
* Description de son utilité
* Problème / Motivation
* Quand appliquer le patron de conception
* Relations problématiques entre les classes
* Solution proposée
* Eléments impliqués
* Leurs relations
* Schémas conceptuels (e.g. diagrammes UML)
* Conséquences
* Compromis éventuels
* Qualité de la solution
Patrons de conception du GoF (2/3)
* Classification selon deux critères
* Cible: qui est concerné ?
* Les classes
* Relations d'héritage
* Aspect statique
* Les instances
* Relations de composition
* Aspect dynamique
* Objectif: que veut-on faire ?
* Création de composants ==> Patrons de création
* Assemblage de composants ==> Patrons de structure
* Comportement des composants ==> Patrons de comportement
Patrons de conception du GoF (3/3)
Principes généraux des design patterns
* Favoriser une bonne conception dès le départ
* "Petit mais costaud"
* Classes spécialisées
* Uniquement les méthodes essentielles
* "Chacun chez soi"
* Eviter les références explicites à d'autres objets
* Le moins de couplage possible
* "Quand on ne sait pas, on demande"
* Déléguer certaines tâches lorsque nécessaire
Mécanisme de délégation (1/2)
* Principe
* Rediriger un message vers un autre objet
* Utilise la composition: délégant vers délégué
* Intervient dans de nombreux patrons du GoF
* Peut être une alternative à l'héritage
* Plusieurs manières de rediriger
* Contrôle du message (e.g. Proxy)
* Changement de message (e.g. Adapter)
* Changement de délégué (e.g. Chain of Responsibility)
* Redéfinition du message (e.g. Decorator)
Mécanisme de délégation (2/2)