Table des matières
Ouvrir table des matières
Comprendre les Designs Pattern
Les Designs Pattern, une expression que vous avez sans doute déjà lu et que vous rencontrerez très souvent dans votre carrière de développeur.
Comme vous allez le voir, les Designs Pattern sont un très bon moyen de pouvoir mettre à profit l’expérience de nos prédécesseurs tout en les personnalisant par rapport à son besoin et sa vision du code.
Source : https://www.commitstrip.com/fr/2020/10/07/the-no-code-dream/ 🔗
Comprendre ce qu’est un Design Pattern
Comme j’en ai déjà parlé brièvement dans mon article sur le pattern MVC, les Design Patterns (ou « Patron de conception 🔗 » en anglais) sont des solutions éprouvées dans le temps et généralisées pour répondre à une problématique récurrente de développeur.
Comme tout patron de conception, c’est un modèle à suivre que vous pouvez appliquer à la lettre ou l’appliquer un peu à votre sauce suivant votre projet et votre niveau en programmation.
La particularité des Design Patterns est qu’ils sont apparus au moment où la programmation orientée objet s’est démocratisée.
D’ailleurs, vous avez rencontré certaines difficultés ou certaines problématiques dans la programmation orientée objet. Il est fort à parier que votre problématique peut être résolue avec un Design Pattern.
Différencier Architectural Pattern et Design Pattern
Quand on parle Design pattern on parle bien de patron de conception, c’est-à-dire qu’un Design Pattern va résoudre une problématique au sein de votre code alors qu’un Architectural Pattern va résoudre une problématique de structure de votre code.
Par exemple, le pattern MVC est un Architectural Pattern. Mais la plupart du temps on dit que le MVC est un Design Pattern. C’est tout simplement un abus de langage.
La seule que vous devez retenir c’est qu’il existe des patterns pour résoudre des problèmes de conception et d’autres au niveau architecture.
L’autre pattern architectural assez connu est le HMVC, mais il y en a un autre qui fait parler de lui depuis quelques années que l’on nomme l’architecture hexagonal 🔗e (que je suis en train d’expérimenter au moment où j’écris ses lignes).
Design Pattern du Gang of Four (GoF)
Je ne parle pas du groupe de musique ni même du jeu de société 🔗, mais bien du groupe qui a fondé le premier livre expliquant et référençant les Design Patterns 🔗. Ce livre date des années 1980 ce qui commence à dater.
Alors pourquoi je vous parle de ce vieux bouquin qui n’est certainement plus à jour 40 ans après ? Tout simplement pour le regroupement des Design Pattern en 3 familles qui sont intéressants à connaître :
- Les Design Patterns de construction
- Les Design Patterns structuraux
- Les Design Patterns comportementaux
Pour ces 3 familles, il y a 23 Design Patterns qui existent et je vais vous les décrire un à un par rapport aux informations que j’ai glanées sur la toile.
Design patterns de construction
Le but de ce type de Design Pattern c’est d’opérer sur le principe de construction et d’instanciation de vos objets afin de les créer ou de les vérifier pour vous.
- Factory 🔗 : il permet de déléguer la création d’objets à une sous-classe
- Abstract Factory 🔗 : il permet la création d’objets d’une même famille sans devoir connaître les classes à instancier.
- Builder 🔗 : il permet de séparer la construction d’objets complexes de leur implantation de sorte qu’un client puisse créer ces objets complexes avec des implantations différentes
- Prototype 🔗 : il permet de créer de nouveaux objets en clonant des objets existants qu’on appelle des prototypes
- Singleton 🔗 : il permet de s’assurer qu’une classe ne possède qu’une seule instance et donc qu’un seul objet de cette classe.
Design patterns structuraux
Le but de ce type de Design Pattern est de faciliter l’indépendance de l’interface d’un objet ou d’un ensemble d’objets par rapport à son implantation pour faciliter la réutilisation.
- Adapter 🔗 : il permet de convertir l’interface d’une classe en une autre interface attendue par une autre classe, ce qui permet de faire travailler des classes malgré leurs interfaces incompatibles.
- Bridge 🔗 : il permet de séparer l’objet de son implémentation d’interfaces
- Composite 🔗 : il permet de gérer un ensemble d’objets en tant qu’un seul et même objet, autrement dit un objet composé de plusieurs autres
- Decorator 🔗 : il permet d’ajouter dynamiquement des fonctionnalités supplémentaires à un objet de manière plus simple et plus efficace à gérer que la notion d’héritage
- Façade 🔗 : il permet de simplifier l’accès à un ensemble d’objets formant un sous-système en fournissant à l’extérieur une interface unifiée. En général, les librairies que vous utilisez dans vos projets utilisent le Design Pattern façade pour simplifier leur utilisation.
- Flyweight 🔗 : il permet de partager des ressources en permettant la mise en oeuvre d’un grand nombre de petits objets
- Proxy 🔗 : il permet de masquer la complexité d’utilisation d’un objet en présentant une interface simplifiée
Design patterns comportementaux
Le but de ce type de Design Pattern est de permettre un échange de traitements et d’algorithmes entre les objets.
- Chain of Responsibility 🔗 : il permet de construire une chaîne d’objets. La responsabilité de l’objet qui accepte une requête doit la traiter. S’il ne peut pas le faire, il passe le relais au suivant et ainsi de suite.
- Command 🔗 : il permet d’encapsuler des requêtes sous forme d’objet
- Iterator 🔗 : il permet d’accéder à des éléments d’un agrégat séquentiellement. On pourrait identifier ce pattern au curseur
- Mediator 🔗 : il permet de construire un objet dont la vocation est la gestion et le contrôle des interactions dans un ensemble d’objets sans que ses éléments doivent se connaître mutuellement
- Memento 🔗 : il permet de restaurer un état précédent d’un objet (retour arrière) sans violer le principe d’encapsulation.
- Observer 🔗 : il permet de définir une relation Observateur-Obersable entre les objets. Quand un objet de type Observable change d’état, il notifie tous les autres objets qui l’observent de son changement pour eux-mêmes changer d’état.
- State 🔗 : il permet, lorsqu’un objet est altéré, de changer son comportement
- Strategy 🔗 : il permet de pouvoir faire permuter des algorithmes au sein d’une application dans certaines conditions
- Template Method 🔗 : il permet de redéfinir certaines étapes d’un algorithme sans modifier la structure de l’algorithme.
- Visitor 🔗 : Il permet de définir une nouvelle opération sans changer les classes des éléments sur lesquels il opère
Faut-il apprendre et utiliser tous les Design Patterns qui existent ?
Je pense que vous vous doutez de la réponse. Non vous ne devez pas tous les apprendre ni même les utiliser.
Moi-même, il y en a beaucoup que je n’ai jamais utilisé et que je n’utiliserais probablement jamais.
Il faut garder dans l’idée qu’un Design Pattern répond toujours à une problématique de conception et que suivant votre application, votre projet et votre expérience, vous n’en aurez pas forcément besoin.
Néanmoins, vous devez avoir conscience que cela existe et que si vous rencontrez un problème de conception en orientée objet alors pensez au Design Pattern que je vous ai cité et explorez-les pour voir si l’un ne répondrait pas à votre problématique.
Les Design Patterns que vous allez forcément utilisés
Par contre, je peux vous garantir qu’il y en a dans cette liste que vous allez systématiquement utiliser tôt ou tard si vous faites de la programmation orientée objet.
Voici la liste :
- Singleton
- Observer
- Decorator
- Adapter
- State
- Prototype
Concentrez-vous sur ceux-là pour commencer surtout que pour le Design Pattern Observer vous allez faire une pierre deux coups !
En effet, ce Design Pattern est le fondement d’un paradigme de programmation qui est autre que la programmation réactive.
Epilogue
L’apprentissage et la maîtrise des Design Pattern sont une étape cruciale pour pouvoir faire de la programmation orientée objet de manière avancée.
Ils vous rendront de fiers services en structurant mieux votre code pour le rendre plus fiable et qualitatif.
Si vous cherchez un bouquin sur le sujet des Design Pattern, car je sais que certains d’entre vous me demandent des livres sur certains sujets, vous pouvez acheter celui-ci 🔗 ou encore celui-là 🔗.
