Dans l’industrie du logiciel, il existe une gamme de sujets sur lesquels vous entendez des débats dans presque toutes les entreprises. Je crois que l’histoire des modèles de conception en fait partie. Vous pouvez trouver d’innombrables messages, articles et réponses Quora/Stackoverflow agissant pour ou contre eux. Par exemple, l’autre jour, je suis tombé sur cette vieille question Quora :
« Pourquoi les programmeurs parlent-ils moins des modèles de conception maintenant ? Quels modèles (le cas échéant) sont encore valables ? »
L’auteur voulait dire des modèles de conception orientés objet, ou les 23 modèles introduits dans le livre Gang of Four, et la plupart des personnes qui ont répondu à la question ont supposé que c’était le cas. Cependant, « le modèle de conception » est un terme que certaines personnes utilisent à la place de « modèles de conception orientés objet » – alors ne soyez pas choqué lorsque vous tombez sur l’étrange déclaration : « les modèles de conception sont morts ».
Dans cet article, nous allons répondre à une question apparemment simple : qu’est-ce qu’un design pattern ? Répondre à cela pourrait nous aider à déterminer de quoi nous parlons lorsque nous discutons ou appliquons un modèle de conception particulier.
Que signifient pour vous les modèles de conception ?
Laissons de côté tous les clichés et concentrons-nous sur ce qui vous vient à l’esprit lorsque vous réfléchissez au concept de design pattern. Est-ce une règle à ne pas enfreindre ? Est-ce une recommandation académique verbeuse ? Est-ce une autre contrainte de conception ? Ou est-ce quelque chose que vous devez seulement savoir pour passer des entretiens d’embauche ?
Pour moi, c’est comme un murmure dans ma tête qui m’empêche de réinventer la roue. Vous avez peut-être ressenti l’envie de démarrer le processus de conception/construction immédiatement après avoir rencontré un problème et créé votre propre solution – si c’est le cas, bienvenue dans le club. Mais dans ce scénario, si une solution existe déjà, en créer une autre prend du temps et des efforts inutiles. Bien que l’envie de se lancer directement dans la création de votre propre solution puisse s’installer avec le temps, je pense que l’un des outils cruciaux pour nous aider à surmonter cette envie est le concept de modèle de conception.
Un modèle de conception me rappelle que de nombreux ingénieurs en logiciel ont déjà été confrontés au même problème et l’ont résolu d’une manière particulière pour plusieurs raisons. Il y a probablement une logique derrière cela et cela nous donne la possibilité de voir le problème sous un angle différent, même si nous n’avons pas l’intention de suivre ce schéma.
Regardons un paragraphe de l’introduction du célèbre livre du GoF :
« Nous connaissons tous la valeur de l’expérience en design. Combien de fois avez-vous eu le déjà-vu du design, ce sentiment que vous avez déjà résolu un problème sans savoir exactement où ni comment ? Si vous pouviez vous souvenir des détails du problème précédent et de la façon dont vous l’avez résolu, vous pourriez alors réutiliser l’expérience au lieu de la redécouvrir.
Plus ou moins, nous avons vécu quelque chose de similaire : résoudre plusieurs fois un problème de conception commun alors que nous ne pouvions pas nous souvenir de la solution précédente. En réutilisant des solutions pour résoudre des problèmes récurrents, les modèles de conception permettent d’économiser du temps et des efforts, qui peuvent tous deux être dirigés ailleurs.
Plongeons maintenant dans quelques concepts et définitions fondamentaux.
Que signifient les motifs ?
Qu’est-ce qu’un motif ? Le concept de modèle n’est pas quelque chose de spécifique à notre industrie. D’autres disciplines et industries telles que l’architecture, l’économie, etc. appliquent également ce concept. Voyons les définitions de modèles par Christopher Alexander, une autorité de premier plan en architecture :
« Chaque modèle est une règle en trois parties, qui exprime une relation entre un certain contexte, un problème et une solution. » (Alexandre, 1979)
« Chaque modèle décrit un problème qui se produit encore et encore dans notre environnement, puis décrit le cœur de la solution à ce problème, de telle sorte que vous pouvez utiliser cette solution un million de fois, sans jamais le faire de la même manière. deux fois. » (Alexandre, 1977)
Voyons maintenant ce que signifient les modèles dans l’industrie du logiciel :
« Un modèle d’architecture logicielle décrit un problème de conception récurrent particulier qui survient dans des contextes de conception spécifiques et présente un schéma générique éprouvé pour sa solution. Le schéma de solution est spécifié en décrivant ses composants constitutifs, leurs responsabilités et leurs relations, ainsi que la manière dont ils collaborent. » (BMRSS, 96)
Sur la base des définitions ci-dessus, nous pouvons considérer un modèle comme une triade de contexte, problème et solution combinés avec la relation entre eux. Cependant, c’est un concept large et peut être appliqué à différentes échelles et niveaux d’abstraction, de la conception d’un système logiciel complet à la résolution d’un problème de conception appartenant à un langage de programmation particulier.
Les différentes catégories de motifs
Les motifs sont classés en fonction de leur échelle et de leur niveau d’abstraction :
- Motifs architecturaux
- Modèles de conception
- Expressions idiomatiques
Les modèles architecturaux se concentrent sur l’ensemble de la structure d’un système logiciel, ses sous-systèmes, les différents composants larges et la façon dont ils s’imbriquent. Ces modèles sont à un haut niveau d’abstraction. Par exemple, ils ne se soucient pas du langage de programmation ou du framework utilisé.
« Un modèle architectural exprime un schéma d’organisation structurel fondamental pour les systèmes logiciels. Il fournit un ensemble de sous-systèmes prédéfinis, précise leurs responsabilités et inclut des règles et des directives pour organiser les relations entre eux. (BMRSS, 96)
D’autre part, nous avons des modèles au niveau d’abstraction le plus bas appelés idiomes qui traitent à la fois de la conception et de la mise en œuvre. Les idiomes sont spécifiques à la langue, ce qui signifie qu’un idiome dans la langue A n’est pas pertinent dans la langue B.
« Un idiome est un modèle de bas niveau spécifique à un langage de programmation. Un idiome décrit comment implémenter des aspects particuliers de composants ou les relations entre eux en utilisant les fonctionnalités du langage donné. (BMRSS, 96)
Cependant, il existe encore d’autres modèles qui se produisent entre ceux mentionnés ci-dessus concernant l’échelle et le niveau d’abstraction, c’est là qu’interviennent les modèles de conception.
Un regard plus attentif sur les modèles de conception
Revoyons donc la définition de la catégorie restante :
« Un modèle de conception fournit un schéma pour affiner les sous-systèmes ou les composants d’un système logiciel, ou les relations entre eux. Il décrit une structure récurrente de composants communicants qui résout un problème de conception général dans un contexte particulier. (BMRSS, 96)
Les modèles de conception sont à échelle moyenne, ce qui signifie qu’ils ne sont ni très abstraits comme les modèles architecturaux, ni couplés à des langages de programmation, comme les idiomes. L’application de modèles de conception n’affecte pas la structure du système logiciel, mais elle a un impact sur l’architecture des sous-systèmes et ses composants plus petits.
Maintenant, discutons de la déclaration suivante (extraite de la même référence) contenant un fait crucial sur les modèles de conception :
« Ils ont tendance à être indépendants d’un langage de programmation particulier ou d’un paradigme de programmation. » (BMRSS, 96)
Selon la catégorie de modèle que nous avons précédemment abordée dans cet article, nous ferions mieux de la reformuler comme ceci :
« Ils sont indépendants d’un langage de programmation particulier mais souvent (pas toujours) dépendant d’un paradigme de programmation.
La première partie de l’énoncé est claire : si un modèle dépend d’un langage de programmation spécifique, il serait dans la catégorie des idiomes. En ce qui concerne la deuxième partie, les modèles de conception sont des tentatives de résolution de problèmes courants qui surviennent dans les paradigmes de programmation. Ce sont probablement des réponses aux déficiences des paradigmes. Par exemple, il existe 23 modèles de conception orientés objet décrits dans le livre GoF, dont la plupart ne sont pas de véritables préoccupations dans le paradigme de la programmation fonctionnelle. Mais l’inverse est également vrai car les modèles de conception ont des contextes différents.
Comme vous pouvez le voir dans l’image suivante, différents paradigmes peuvent partager des modèles de conception, mais nous n’aborderons pas ce sujet car il dépasse le cadre de cet article.
Analyser une déclaration célèbre
En gardant à l’esprit les sections précédentes, examinons rapidement une déclaration que vous pouvez rencontrer lorsque vous recherchez simplement des modèles de conception sur Google :
Les langages fonctionnels n’ont pas besoin de modèles de conception.
Vous pouvez trouver un échantillon ici. Cette affirmation est fausse car elle implique que les modèles de conception n’appartiennent qu’au paradigme orienté objet. Cependant, les modèles de conception sont un concept qui peut être présent à la fois dans le paradigme de la programmation fonctionnelle et dans le paradigme orienté objet. Les modèles de conception peuvent simplement être spécifiques aux problèmes et aux exigences du paradigme hôte. Par exemple, le paradigme de la programmation fonctionnelle a des modèles de conception spécifiques à son contexte.
De plus, comme nous l’avons vu dans les sections précédentes, différents paradigmes ont des contextes différents et rencontrent par conséquent des problèmes différents. Nous ne devrions pas nous attendre à ce que les modèles de conception du paradigme B résolvent les problèmes du paradigme A.
Un récapitulatif rapide
Les modèles de conception, similaires aux autres types de modèles, tentent de résoudre les problèmes récurrents d’un contexte particulier.
- Ils sont indépendants de la langue mais principalement couplés au paradigme.
- Étant de taille moyenne, ils ne sont pas aussi abstraits que les modèles architecturaux.
- Leur application n’affecte pas l’architecture fondamentale du système logiciel mais influence l’architecture des sous-systèmes.
- Enfin et surtout, ce sont (tous les types de motifs) des moyens de nous empêcher de réinventer la roue.
De mon point de vue, les modèles de conception ne sont pas des lois strictes pour contraindre notre conception. Ils ne sont ni fixes ni parfaits car ils pourraient évoluer et s’améliorer ou même disparaître, mais le concept de modèle existe toujours. Suivre des modèles est comme un état d’esprit qui nous aide à comprendre qu’il pourrait y avoir une meilleure solution.