Dans le vaste univers des design patterns, certains sont omniprésents dans les tutoriels (comme Singleton, Observer ou Factory), tandis que d’autres, bien que puissants, restent largement sous-estimés.
Cet article met en lumière 4 patterns souvent négligés mais extrêmement efficaces dans des contextes bien précis : optimisation mémoire, modularité, réutilisabilité et gestion des flux conditionnels.
1. Flyweight Pattern (Patron de conception Poids-Mouche)
Le Flyweight Pattern vise à minimiser l'utilisation de la mémoire en partageant les données communes entre plusieurs objets.
Il est particulièrement utile dans des contextes où un très grand nombre d’objets similaires sont instanciés.
➕ Cas d’usage typique :
- Moteurs de rendu graphique (ex. : objets identiques dans un jeu vidéo)
- Éditeurs de texte avec millions de caractères (chaque caractère est un objet)
🎯 Pourquoi il est sous-coté :
Parce qu’il est moins enseigné que d'autres et souvent perçu comme complexe à implémenter. Pourtant, il peut améliorer drastiquement les performances dans des environnements contraints en ressources.
2. Proxy Pattern (Patron de conception Proxy)
Le Proxy Pattern consiste à créer un substitut à un objet réel afin de contrôler ou modifier son accès.
➕ Cas d’usage typique :
- Mise en cache de résultats lourds
- Sécurisation d’accès à des ressources sensibles
- Lazy loading (chargement différé)
🎯 Pourquoi il est sous-coté :
Souvent considéré comme “trop abstrait” ou “trop orienté framework”, alors qu’il permet en réalité une grande modularité et une séparation des responsabilités très claire.
3. Template Method Pattern (Patron de conception Modèle de méthode)
Le Template Method Pattern définit le squelette d’un algorithme dans une classe de base, tout en laissant les étapes spécifiques à des sous-classes.
➕ Cas d’usage typique :
- Processus industriels ou métiers ayant un cadre fixe mais des variations locales
- Frameworks où certaines étapes sont définies par le développeur (hook methods)
🎯 Pourquoi il est sous-coté :
Moins “flexible” qu’un Strategy Pattern en apparence, il est pourtant simple, robuste et très réutilisable, idéal pour éviter la duplication de logique métier.
4. Chain of Responsibility Pattern (Patron de conception Chaîne de responsabilité)
Ce pattern permet de chaîner plusieurs objets qui vont se transmettre une requête jusqu’à ce qu’un objet la traite.
➕ Cas d’usage typique :
- Gestion des middlewares dans les API (Express, NestJS, etc.)
- Chaînes de validation ou de traitement conditionnel
🎯 Pourquoi il est sous-coté :
Peu structurant à première vue, il est parfois vu comme “flou” en conception. Pourtant, il est extrêmement puissant pour créer des systèmes extensibles et découplés.
Ne sous-estimez pas ces patterns
La sous-utilisation de certains design patterns vient souvent d’un manque de familiarité ou de cas d’usage bien documentés. Pourtant, chaque pattern a un potentiel énorme quand il est utilisé dans le bon contexte.
Avant de choisir le “pattern à la mode”, prenez le temps de :
- comprendre les contraintes de votre projet,
- identifier les objectifs techniques à atteindre (performance, lisibilité, extensibilité),
- et choisir le pattern le plus adapté, même s’il est sous-coté.
