Chapitre 5.4.10Les design patterns

Les développeurs rencontrent sans cesse les mêmes problèmes. Comment créer un objet complexe ? Comment s'assurer qu'il n'y a qu'un seul exemplaire d'un composant ? Comment organiser les interactions entre l'interface et la logique métier ? Plutôt que de réinventer la roue, la communauté a formalisé des solutions éprouvées. Ce sont les design patterns.

Un design pattern n'est pas du code tout fait qu'on installe. C'est une recette, une façon connue d'agencer des objets pour résoudre un problème récurrent. Deux applications qui utilisent le même pattern n'ont pas une ligne de code en commun, mais elles sont organisées pareil.

Le Gang of Four

En 1994, quatre auteurs publient un livre devenu une bible du développement : "Design Patterns: Elements of Reusable Object-Oriented Software". Ces quatre auteurs sont surnommés le Gang of Four (GoF). Leur livre catalogue 23 design patterns classés en trois catégories :

• Créationnels : comment créer des objets de manière flexible. Par exemple, le pattern Factory : au lieu de créer un objet directement, on délègue la création à une "usine" qui choisit quel type d'objet construire selon le contexte. Imagine un service de livraison : selon la destination, l'usine choisit d'envoyer par vélo, camionnette ou avion, sans que le reste du programme ait besoin de connaître ces détails.
• Structurels : comment assembler des petites briques pour en faire des structures plus complexes tout en gardant le système flexible. Par exemple, le pattern Decorator, qui emballe un objet dans un autre pour lui ajouter un comportement. C'est le principe des options d'un café, un expresso reste un expresso, on l'entoure d'un supplément lait puis d'un supplément sirop.
• Comportementaux : comment les objets communiquent et se partagent les responsabilités. Par exemple, le pattern Observer : un objet prévient automatiquement tous les intéressés quand quelque chose change. C'est exactement le principe des notifications sur ton téléphone.

Le Singleton

Le pattern le plus simple et le plus controversé. Un Singleton garantit qu'il n'existe qu'une seule instance d'un objet dans tout le programme.

Le cas d'école, c'est la connexion à la base de données. Tu ne veux pas ouvrir une nouvelle connexion à chaque requête, tu veux réutiliser la même. Le Singleton s'en charge.

Pourquoi controversé ? Parce qu'il est souvent mal utilisé. Les débutants en mettent partout, ce qui revient à créer des variables globales déguisées, et rend le code difficile à tester et à faire évoluer. Si tu hésites, c'est probablement que tu n'en as pas besoin.

MVC : Model View Controller

S'il y a un pattern que tout le monde connaît dans le développement web, c'est le MVC. Il ne fait pas partie des 23 du Gang of Four et leur est même antérieur, puisqu'il a été imaginé à la fin des années 1970 par le Norvégien Trygve Reenskaug. Il sépare une application en trois composants :

• Le Modèle : les données et la logique métier. "Un client a un nom, un email, et peut passer une commande."
• La Vue : ce que l'utilisateur voit. La page web, le formulaire, le tableau de bord.
• Le Contrôleur : le chef d'orchestre qui reçoit les actions de l'utilisateur, les transmet au modèle et met à jour la vue.

Quand tu cliques sur "Ajouter au panier" sur un site e-commerce, le contrôleur reçoit l'action, demande au modèle d'ajouter le produit, puis met à jour la vue pour afficher le nouveau contenu du panier.

Cette séparation permet à un designer de modifier l'interface sans toucher à la logique métier, et à un développeur back-end de changer la façon dont les données sont stockées sans impacter ce que l'utilisateur voit.

Le MVC a essaimé. Les frameworks modernes en proposent des variantes (MVVM, architectures à composants), mais l'intention reste la même, ne jamais mélanger ce qui s'affiche, ce qui décide et ce qui stocke.

Ceux que tu entendras en réunion

Tu n'as aucune raison de connaître les 23 patterns du livre. En revanche, quelques noms reviennent régulièrement dans la bouche des équipes, tous ne venant d'ailleurs pas du Gang of Four, et savoir ce qu'ils désignent évite de décrocher.

• Repository : une couche qui isole l'accès aux données. Le reste du code demande "donne-moi le client 42" sans savoir si ça vient d'une base de données, d'un fichier ou d'une API. Celui-là ne vient pas du livre du Gang of Four mais de Martin Fowler, un autre auteur incontournable du domaine.
• Strategy : plusieurs façons de faire la même chose, interchangeables. Un calcul de frais de port qui change selon le transporteur, sans un if géant qui les liste tous.
• Adapter : une pièce de conversion entre deux composants qui ne parlent pas la même langue. Typiquement pour brancher un service externe sans contaminer tout le code avec son vocabulaire à lui.
• Facade : une porte d'entrée unique et simple devant un sous-système compliqué, pour n'exposer que ce qui sert vraiment.

Pourquoi c'est important ?

Les design patterns sont un vocabulaire commun entre développeurs. Quand quelqu'un dit "j'ai mis en place un Observer", tout le monde comprend immédiatement le mécanisme, sans avoir besoin d'une explication détaillée.

Comme tous les outils, les design patterns sont utiles quand ils résolvent un vrai problème. Les utiliser pour le plaisir d'utiliser un pattern, c'est de la sur-ingénierie. Le piège est classique, on apprend les patterns et on veut les appliquer partout, même là où un simple if aurait suffi.

L'expérience, c'est savoir quand utiliser un pattern, pas juste comment.