Que se passerait-il si vous conduisiez une voiture et qu'un pneu crevait ? Ce problème est suffisamment fréquent pour que certaines personnes aient réfléchi à sa solution (autre qu'appeler au secours, bien sûr...). La solution est la roue supplémentaire dans votre coffre, juste au cas où. On l'appelle la roue de secours.
C'est un exemple de design pattern. Un problème qui survient si souvent qu'on lui attribue un nom et une solution connue. Je n'ai qu'à utiliser les mots "roue de secours" pour que vous sachiez immédiatement de quoi je parle. Cependant, chaque véhicule applique ce principe de manière différente. Certaines roues de secours sont petites et d'autres sont de taille normale. Certaines sont faciles à trouver dans le coffre, et d'autres non. Mais l'essentiel est que vous me compreniez quand je parle de roue de secours.
Qu'est-ce qu'un design pattern ?
Un design pattern est une solution testée et réutilisable appliquée à un problème récurrent. Il décrit la nature statique ou dynamique des classes et des objets qui implémentent la solution. Vous êtes libre de personnaliser la solution en fonction de votre situation particulière, comme la dimension de la roue de secours, par exemple.
Les patterns sont généralement caractérisés par quatre attributs :
nom ;
problème ;
solution ;
conséquences.
Le nom vous permet de décrire la situation à un "niveau élevé". Dans un langage universel.
Le problème décrit la situation à laquelle peut être appliqué le pattern. C'est la partie la plus complexe – être capable de reconnaître le problème existant et de choisir le pattern approprié. Par exemple, dans notre jeu de carte, nous devons créer des jeux différents, contenant des numéros de cartes différents. Un pattern existe pour ce cas de figure !
La solution décrit l'assemblage des classes et des objets qui vont rendre le pattern opérationnel. Même si vous pouvez réaliser quelques modifications pour vous adapter à votre cas personnel, vous devez conserver l'esprit du pattern. Par exemple, nous utiliserons un pattern pour créer nos paquets de cartes. Le pattern ne nous renseigne pas sur la façon de créer des jeux de cartes, mais nous fournit plutôt une vue d'ensemble de la création d'objets en tout genre.
Les conséquences sont ce qui se produit lorsque vous appliquez le pattern. Chaque pattern dispose au moins d'une conséquence positive. Il résout le problème. Mais il arrive parfois qu'il ait des conséquences négatives. Par exemple, avec la roue de secours : la taille de la roue a un impact sur votre capacité à transporter d'autres objets dans le coffre.
D'où viennent les patterns ?
En 1994, la bande des quatre, ou « Gang of Four » (Erich Gamma, Richard Helm, Ralph Johnson et John Vlissides), a publié le livre Design patterns: Elements of Reusable Object-Oriented Software. Ces quatre auteurs ont examiné plus de 300 projets sur lesquels travaillaient d'autres développeurs. Ils se sont rendu compte que les mêmes problèmes réapparaissaient sans cesse.
Ils ont également remarqué que ces divers projets résolvaient lesdits problèmes d'une façon globalement similaire. Leur livre aborde ces problèmes et leurs solutions, en les appelant « patterns ». Ils ont classé les patterns en trois sections :
Les patterns de création – des patterns ayant trait à la création d'objets.
Les patterns de structure – qui ont trait à l'organisation des classes et des objets.
Les patterns de comportement – qui ont trait aux interactions entre les objets.
Dans cette partie, nous analyserons des exemples de ces trois types.
Pourquoi utiliser un design pattern ?
Vous rencontrez systématiquement des problèmes lors de la structuration d'un logiciel. Vous pouvez toujours « bidouiller » une solution, mais cela entraîne des problèmes difficiles à résoudre sur le long terme. Vous souhaitez éviter les mauvaises pratiques de programmation. Savoir reconnaître les patterns est une des méthodes permettant de garantir un code "propre".
Le principal avantage d'un design pattern est qu'il vous permet d’être sûr que la solution fonctionne. Vous n'êtes pas dispensé de réfléchir, mais cela vous évite de réinventer la roue.
Voyons d'autres avantages.
Tout d'abord, l'intelligibilité du code. Les patterns sont déjà correctement documentés. Vous n'avez pas besoin de rejustifier vos choix d'organisation. Vous savez déjà quel doit être le résultat en termes d'implémentation. Il s'agit simplement de gérer les spécificités inhérentes à votre code.
Un autre avantage concerne l’amélioration de la communication entre les développeurs : vous n'avez pas besoin d’expliquer en détail vos choix de conception, vous pouvez directement faire référence au nom du ou des pattern(s) que vous avez choisi(s). Je n'ai pas besoin de dire, « Avez-vous l'une de ces roues supplémentaires dans votre coffre, au cas où vous seriez victime d'une crevaison ? ». Je n'ai qu'à demander si vous avez une roue de secours : vous savez de quoi je parle .:honte:
En résumé
Les patterns sont des solutions testées et réutilisables qui sont appliquées à des problèmes récurrents.
Quatre mots décrivent les patterns :
nom ;
problème ;
solution ;
conséquences.
L'utilisation de patterns conduit à une meilleure compréhension et une plus grande maintenabilité.
Il existe trois types de patterns :
de création ;
de structure ;
de comportement.
Dans le prochain chapitre, nous examinerons le premier ensemble de patterns : ceux dédiés à la création d'objets, appelés "patterns de création".
