Aller au contenu
gaetancottrez.dev

Comprendre les Design Patterns

Published:le  à 05:00 | (7 min de lecture)
Comprendre les Design Patterns

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.

Commitstrip No 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 :

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.

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.

Design patterns comportementaux

Le but de ce type de Design Pattern est de permettre un échange de traitements et d’algorithmes entre les objets.

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 :

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à 🔗.

Vous pourriez aussi aimer

Architecture hexagonale : reprenez le contrôle du code métier

Architecture hexagonale : reprenez le contrôle du code métier

Structurer votre code avec le pattern MVC

Structurer votre code avec le pattern MVC

Article précédent
Architecture hexagonale : reprenez le contrôle du code métier
Article suivant
Quel type de base de données choisir ?