Pourquoi utiliser des design patterns ?
Tout simplement parce qu'ils sont pratiques. Vous êtes-vous déjà trouvé face à un problème récurrent et pour lequel vous saviez qu'il existait une meilleure solution que la vôtre ? C'est là que les patterns entrent en jeu. Comme toutes les autres disciplines, la programmation implique de résoudre de nombreux problèmes, et utiliser des solutions communes peut éviter les erreurs, faire gagner du temps et simplifier la compréhension de votre code par les autres développeurs.
Qu'est-ce qu'un design pattern ?
Dans la partie 2, nous avons vu les principes SOLID et STUPID, conçus pour vous aider à créer du code plus propre et moins couplé. Vous l'avez peut-être remarqué dans nos exemples, certaines structures tendent à rendre votre code plus conforme aux principes SOLID. Par conséquent, vous ne serez pas surpris d'apprendre que la prochaine étape à suivre pour écrire du code SOLID consiste à implémenter de telles structures, que l'on appelle des design patterns.
Un design pattern, ou patron de conception, est une solution à un problème qui revient régulièrement. Pour citer un célèbre architecte qui a construit des immeubles et des villes entières :
Les éléments de ce langage sont des entités appelées patrons. Chaque patron décrit un problème qui revient régulièrement dans notre environnement, et donc 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.
L'explication de Christopher Alexander, qui se trouve de son livre A Pattern Language: Towns, Buildings, Construction, colle parfaitement aux design patterns de la conception orientée objet. Leur utilisation présente de nombreux avantages, notamment :
Ré-utilisabilité
Solutions à des problèmes fréquents de programmation
Délai de développement plus court
Fiabilité (ils sont éprouvés)
Clarté de l'architecture système et possibilité de créer un meilleur système
Ces avantages vous rappellent quelque chose ? C'est bien normal : les principes SOLID sont étroitement liés aux design patterns. À mesure que vous découvrirez les design patterns, vous vous rendrez compte que vous en utilisiez déjà sans le savoir. C'est une excellente chose ! L'objectif de ce cours est de savoir les reconnaître et de comprendre dans quelles situations les utiliser.
De manière générale, un design pattern se compose de quatre éléments :
Nom du pattern
Problème (situation dans laquelle appliquer le pattern)
Solution (éléments composant le design pattern)
Conséquences (résultats, avantages et inconvénients à utiliser le pattern)
Commençons par nous pencher sur les origines des design patterns dans l'univers des logiciels.
Le "Gang of Four"
Les design patterns n'ont commencé à gagner en popularité qu'à partir de 1994, grâce à Eric Gamma, Ralph Johnson, Richard Helm et John Vlissides.
Ces quatre développeurs étaient surnommés le "Gang of Four". Ils ont défini 23 patterns répartis en 3 groupes :
Patterns de création : pour la création d'objets.
Fabrique abstraite (AbstractFactory) : pour créer une instance de plusieurs familles de classes.
Monteur (Builder) : découple la construction d'un objet de sa représentation.
Fabrique (FactoryMethod) : crée une instance de plusieurs classes connexes.
Prototype : fournit une instance totalement initialisée à copier ou cloner.
Singleton : classe dont une seule instance peut exister.
Patterns de structure : pour créer des objets volumineux et complexes.
Adaptateur (Adapter) : permet d'interconnecter les interfaces de classes différentes.
Pont (Bridge) : découple l'interface d'un objet de son implémentation.
Composite : fournit une structure arborescente d'objets simples et composites.
Décorateur (Decorator) : ajoute des responsabilités à des objets de manière dynamique.
Façade (Facade) : fournit une classe unique représentant l'intégralité d'un sous-système.
Poids-mouche (Flyweight) : fournit une instance fine utilisée pour réaliser un partage efficace.
Proxy : fournit un objet représentant un autre objet.
Patterns de comportement : pour les algorithmes et les relations avec les objets.
Chaîne de responsabilité (Chain of Responsibility) : transmet une requête au sein d'une chaîne d'objets.
Commande (Command) : encapsule une requête dans un objet.
Interpréteur (Interpreter) : inclut des éléments de langage dans un programme.
Itérateur (Iterator) : offre un accès séquentiel aux éléments d'un ensemble.
Médiateur (Mediator) : définit une communication simplifiée entre des classes.
Mémento (Memento) : stocke et restaure l'état interne d'un objet.
Observateur (Observer) : notifie plusieurs classes d'un changement.
État (State) : modifie le comportement d'un objet lorsque son état change.
Stratégie (Strategy) : encapsule un algorithme dans une classe ;
Patron de méthode (TemplateMethod) : délègue les étapes précises d'un algorithme à une sous-classe.
Visiteur (Visitor) : définit une nouvelle opération pour une classe sans la modifier.
Comment savoir quand utiliser un utiliser un design pattern ?
C'est une très bonne question ! Certes, il est bien d'apprendre à utiliser les design patterns, mais il vous faudra du temps pour reconnaître les situations concrètes dans lesquelles les appliquer. Pourquoi ? Parce que c'est en progressant en tant que développeur que vous commencez à voir ces problèmes récurrents et que vous vous direz : "Hé, ça c'est du déjà vu, et je sais comment le gérer !"
Dans les chapitres suivants, nous allons analyser plus en détail certains de ces design patterns. Nous verrons également dans quels cas les utiliser.
En résumé
Un design pattern est une solution à un problème récurrent.
Les design patterns sont réutilisables, éprouvés et contribuent à l'amélioration des systèmes.
Ils se composent de quatre éléments : un nom, un problème, une solution et des conséquences.
En 1994, le "Gang of Four" a publié un livre intitulé "Design Patterns: Elements of Reusable Object-Oriented Software". Il définit 23 design patterns répartis en trois groupes : patterns de création, de structure et de comportement.
Maintenant que vous avez compris l'intérêt des design patterns, penchons-nous sur le premier groupe, les patterns de création.
