Le Gang of Four a-t-il exploré en profondeur «l'espace-modèle»?

Depuis que j'ai découvert les modèles de conception Gang of Four (GoF) , il y a au moins 10 ans, j'ai l'impression que ces 23 modèles ne devraient constituer qu'un petit échantillon de quelque chose de beaucoup plus grand que j'aime appeler l' espace-modèle . Cet espace de modèle hypothétique comprend toutes les solutions recommandées (connues ou inconnues) aux problèmes courants de conception de logiciels orientés objet.

Je pensais donc que le nombre de modèles de conception connus et documentés augmenterait considérablement.

Cela ne s'est pas passé Plus de 20 ans après la publication du livre GoF, l'article de Wikipedia ne contient que 12 motifs supplémentaires, dont la plupart sont beaucoup moins populaires que les originaux. (Je n'ai pas inclus les modèles de concurrence ici car ils couvrent un sujet spécifique.)

Quelles sont les raisons?

• L'ensemble de modèles du GoF est-il réellement plus complet que je ne le pense?

• L'intérêt de trouver de nouveaux modèles a-t-il chuté, peut-être parce qu'ils se sont avérés inutiles dans la conception de logiciels?

• Autre chose?

Lorsque le livre a été publié, beaucoup de gens ont pensé de la sorte et beaucoup d’efforts ont été faits pour créer des "bibliothèques de modèles" ou même des "communautés de modèles". Vous pouvez encore en trouver:

• "Communauté de modèles" , WikiWikiWeb
• "Groupe d'étude sur les modèles de conception de la ville de New York" , Logique industrielle
• "Catalogue de modèles" , The Hillside Group

Mais alors...

L'intérêt de trouver de nouveaux modèles a-t-il chuté, peut-être parce qu'ils ne sont pas vraiment utiles à la conception de logiciels?

Ceci, beaucoup. L’intérêt des modèles de conception est d’améliorer la communication entre les développeurs, mais si vous essayez d’ajouter d’autres modèles, vous en arriverez rapidement au point où les gens ne peuvent plus s’en souvenir, ou les mémorisent mal, ou ne sont pas d’accord sur ce à quoi ils devraient ressembler, et la communication est pas amélioré, en fait. Cela arrive déjà souvent avec les patterns GoF.

Personnellement, j'irais même plus loin: la conception de logiciels, en particulier de bonne conception, est beaucoup trop variée pour être capturée de manière significative dans les motifs, en particulier dans le petit nombre de motifs que les gens peuvent réellement se souvenir - et ils sont beaucoup trop abstraits rappelez-vous vraiment plus d'une poignée. Donc, ils n'aident pas beaucoup.

Et beaucoup trop de personnes sont séduites par le concept et tentent d'appliquer des motifs partout - généralement, dans le code résultant, vous ne trouvez pas le dessin réel entre tous les Singletons (complètement dénués de sens) et les Abstract Factories.

J'ai l'impression que ces 23 motifs ne devraient constituer qu'un petit échantillon de quelque chose de beaucoup plus grand que j'aime appeler l'espace-motifs.

C’est la terrible supposition qui est propagée par les programmeurs néophytes du monde entier, des programmeurs qui pensent qu’ils peuvent écrire un programme simplement en assemblant des modèles logiciels. Ça ne marche pas comme ça. S'il existe un tel "espace de modèle", vous pouvez supposer que sa taille est effectivement infinie.

Les modèles de conception (au sens de GoF) n'ont qu'un but: compenser les lacunes du langage de programmation que vous utilisez.

Les modèles de conception ne sont ni universels ni complets. Si vous passez à un langage de programmation différent et plus expressif, la plupart des modèles du livre GoF deviennent à la fois inutiles et indésirables.

Je pense que trois facteurs entrent en jeu ici.

Manque de masse critique

Premièrement, un motif est en gros un peu plus que de donner un nom à un code qui implémente un "bloc" de fonctionnalités particulier. La seule façon dont ce nom offre une réelle valeur réelle est que si vous pouvez compter sur le fait que tout le monde sait ce que le nom signifie, alors simplement en utilisant le nom, ils comprennent immédiatement beaucoup de choses sur le code.

Les modèles n’ont jamais établi la masse critique dont ils avaient besoin pour y parvenir. Plutôt le contraire, AAMOF. Au cours des quelque 20 années qui se sont écoulées depuis la publication du livre du GoF, je suis presque certain de n'avoir jamais assisté à une douzaine de conversations au cours desquelles toutes les personnes impliquées connaissaient réellement suffisamment de motifs pour leur permettre d'améliorer la communication.

Pour le dire légèrement plus étrangement: les modèles de conception ont échoué spécifiquement parce qu'ils ont échoué.

Trop de motifs

Je pense que le deuxième facteur majeur est qu’ils ont au départ nommé trop de motifs. Dans un bon nombre de cas, les différences entre les modèles sont suffisamment subtiles pour qu'il soit presque impossible de dire avec une certitude réelle si une classe particulière correspond à un modèle (ou peut-être les deux - ou peut-être aucune).

L'intention était que vous puissiez parler du code à un niveau supérieur. Vous seriez en mesure d’étiqueter un gros morceau de code comme l’implémentation d’un modèle particulier. En utilisant simplement ce nom prédéfini, chaque personne à l'écoute en sait généralement autant qu'elle se soucie de ce code, afin que vous puissiez passer à autre chose.

La réalité tend à être presque le contraire. Disons que vous êtes en réunion et dites-leur que cette classe est une façade. La moitié des participants à la réunion n’ont jamais su ou ont oublié depuis longtemps ce que cela signifie. L'un d'eux vous demande de lui rappeler la ou les différences exactes entre une façade et, par exemple, un proxy. Oh, et les quelques personnes qui connaissent vraiment les habitudes passent le reste de la réunion à débattre de la question de savoir si cela devrait vraiment être considéré comme une façade ou "juste" comme un adaptateur (ce type insistant toujours sur le fait que cela ressemble à une procuration).

Étant donné que votre intention était vraiment juste de dire: "ce code n'est pas très intéressant, passons à autre chose", essayer d'utiliser le nom d'un motif ne faisant qu'ajouter à la distraction, pas à la valeur.

Manque d'intérêt

La plupart des modèles de conception ne traitent pas vraiment des parties de code intéressantes. Ils traitent de choses telles que: "comment créer ces objets?" Et "comment faire en sorte que cet objet parle à celui-ci?" La mémorisation de noms de motifs pour ceux-ci (ainsi que les arguments susmentionnés portant sur les détails et autres) met simplement beaucoup d'énergie dans des tâches que la plupart des programmeurs ne se soucient tout simplement pas trop de faire.

Pour le dire légèrement différemment: les modèles traitent des choses qui sont identiques entre beaucoup de programmes - mais ce qui rend vraiment un programme intéressant, c'est sa différence par rapport aux autres programmes.

Sommaire

Les modèles de conception ont échoué parce que:

1. Ils n'ont pas réussi à atteindre une masse critique.
2. La différenciation entre les motifs était insuffisante pour garantir la clarté.
3. La plupart du temps, ils traitaient des parties du code dont presque personne ne se souciait vraiment.

Les motifs manquent d'abstractions, les motifs simples sont abstraits, les motifs complexes ne sont pas reconnus et les motifs ne sont donc pas utiles (à l'exception de quelques modèles de haut niveau).

Je pense que Paul Graham l'a dit le mieux:

Quand je vois des modèles dans mes programmes, je le considère comme un signe de problème. La forme d’un programme ne devrait refléter que le problème qu’il doit résoudre. Toute autre régularité dans le code est un signe, du moins pour moi, que j'utilise des abstractions qui ne sont pas assez puissantes - souvent que je génère à la main les extensions d'une macro que je dois écrire.

Lorsque vous reconnaissez un motif dans votre code, cela signifie que quelque chose se répète et que vous devez utiliser une meilleure abstraction. Si vous n'avez pas une meilleure abstraction, vous utilisez le modèle comme solution de contournement. Comme les nouveaux langages de programmation fournissent de meilleures abstractions, les modèles deviennent beaucoup moins utiles.
De plus, les schémas simples sont souvent facilement abstraits et les schémas complexes rarement reconnus.
Quand un motif est remplacé par une abstraction, cela ne signifie pas que le concept derrière le motif disparaît, mais que le concept peut être écrit explicitement au lieu d’indirect, et qu’il n’est plus spécial par rapport à un autre code et qu’il ne devient plus reconnaissable comme tel. un motif.

Bien que je sois en grande partie d’accord avec ce que les autres ont répondu ici, je pense personnellement que l’un des principaux motifs d’un nombre non croissant de motifs est qu’ils perdent leur sens quand ils sont innombrables. La bonne chose avec ces quelques modèles est qu'ils couvrent un grand nombre de domaines problématiques de manière standard. Si vous vous concentrez sur un domaine de motifs infini, vous vous retrouverez sans motif. C'est un peu comme "combien de temps dure la ligne de côte d'une île?". Si vous mesurez sur une carte, vous obtenez un nombre décent. Mais si vous essayez d’être plus précis et d’obtenir une résolution plus fine, vous constaterez que la longueur augmente de plus en plus à l’infini (ou l’incertitude; comment mesureriez-vous la frontière exacte avec les marées et au niveau atomique?).

Quelque chose qu'aucune autre réponse ne mentionne est également pertinent:

La montée des langages à typage dynamique.

Lorsque le livre a été publié pour la première fois, il a été sérieusement discuté du fait que Java était trop lent pour effectuer un travail réel. Maintenant, Java est fréquemment utilisé dans des langages plus expressifs en raison de sa rapidité. Peut-être que Ruby, Python, JavaScript, etc. sont encore trop lents pour certaines classes importantes d’applications, mais qu’ils sont assez rapides pour la plupart des applications. Et au moins JavaScript s’accélère, même si chaque version contient plus de fonctionnalités.

Le livre original GoF avait les motifs à la fois en smalltalk et en c ++, et si la mémoire sert, les motifs étaient toujours plus courts en smalltalk et parfois considérablement. Certaines des caractéristiques des modèles de conception classiques constituent en réalité des moyens d’ajouter des caractéristiques dynamiques à un système à typage statique (comme AbstractFactory, déjà évoqué, dans lequel vous instanciez la classe correcte en fonction des données d’exécution). D'autres sont tellement plus courts dans les langages dynamiques qu'ils se fondent simplement dans une utilisation idiomatique du langage lui-même.

Il ne se produit. Des dizaines, voire des centaines de livres ont été publiés dans ce qui semblait être une tentative de réduire toute la science informatique à des schémas de conception, les éditeurs et les auteurs essayant de sauter (ou de créer) un autre train en marche. J'en ai une étagère. Jamais consulté depuis le premier balayage, et oui j'étais un meunier, parce qu'il y avait peu ou rien d'utilisation réelle ou qui était déjà mal connu (voir par exemple Type Object, qui n'est rien de plus qu'une troisième forme normale exprimée une douzaine de pages au lieu d’un paragraphe), et parce qu’il est évident que moins il ya de motifs, mieux c’est: un point qui a échappé à la plupart des praticiens. En effet, lorsque j'ai posté une réfutation de Type Object, on m'a demandé de reformuler mon texte en tant que motif de conception.Histoire vraie. Ce qui montre également une autre lacune du projet: pas de mécanisme d’examen, d’exclusion ou de rejet.

En fait, le GoF n'a pas réellement essayé d '"explorer en profondeur les modèles de conception". Au contraire, ils étaient engagés dans un projet beaucoup plus vaste: introduire un langage de modèle dans CS, avec tous ses arcanes notionnels de Forces, Participants, etc., qui ont simplement échoué, car il était fondamentalement mal conçu et inutile.

Ce qu’ils ont accompli, ce qui était utile, c’est deux choses:

• publier plusieurs astuces utiles telles que le modèle Visiteur
• fournissez un ensemble standard de noms qui est en grande partie bloqué: Factory, Adapter, Iterator, ... Si vous regardez CORBA, qui a été conçu tout à l’heure, vous verrez tout son intérêt: toutes sortes de noms "étrangers" tels que Interceptor , Serviteur, courtier, ...

Un autre concept utile qui a vu le jour était «anti-modèle», par exemple «journalier et lancer». Le projet, comme beaucoup de manies dans CS, a été déraillé par son propre évangélisation et par avoir été adopté à tort comme une autre religion du CS. ) Fred Brooks, 1965). Triste que nous devions continuer à redécouvrir cela toutes les quelques années vraiment.

Il existe plusieurs ouvrages intitulés PLoP ( Pattern Languages ​​of Design Programme ), qui sont chacun une anthologie d’articles présentés à une conférence annuelle .

En lisant les livres, j'ai trouvé que certains des motifs étaient intéressants et nouveaux pour moi, dont certains étaient des standards (par exemple, "demi-objet plus protocole").

Donc, non, la collection du GoF n'était pas exhaustive, et inspirait / inspirait les gens à collectionner / décrire / découvrir / inventer de nouveaux.

Les "seuls 12 modèles supplémentaires énumérés dans l'article de Wikipedia" ne sont probablement pas une collection complète non plus: c'est-à-dire qu'il en existe d'autres documentés ailleurs, par exemple dans les livres PLoP et peut-être aussi ailleurs.

Le livre Gang of Four (GoF) contient la plupart des modèles qu'un programmeur expérimenté utilisant un langage non fonctionnel possède dans sa ceinture d'outils. C'est comme l'ensemble d'outils de base que tous les constructeurs savent utiliser. La principale contribution de l'ouvrage était de donner un nom bien défini aux modèles couramment utilisés par les programmeurs les plus expérimentés de l'époque, et donc de faciliter la communication entre les programmeurs discutant des options de conception.

Vous vous attendez à ce qu'un électricien dispose de certains outils qu'un constructeur normal ne possède pas. De même, vous vous attendez à ce qu'un programmeur WPF connaisse les modèles de conception de «Propriétés de dépendance» ou qu'un «programmeur SQL» connaisse le modèle de conception permettant d'utiliser des déclencheurs créer des données d'audit.

Cependant, nous ne les considérons pas comme des «modèles de conception», car ils ne sont utilisés qu'avec une seule technologie.

Quelques autres modèles de modèles modernes sont «Refactoring, Amélioration de la conception de code existant (Martin Fowler)» et «Code propre: un manuel d'artisanat logiciel agile (Robert C. Martin) ». Ces deux livres présentent le contenu sous forme de transformations. à votre code actuel, plutôt que comme "conception réutilisable pré-en conserve", mais ils sont tout aussi "modèles de conception".

Voici une interview avec Erich Gamma où il réfléchit sur leur sélection de motifs et sur ce qu’ils changeraient aujourd’hui (bien aujourd’hui il ya 10 ans, haha).

http://www.informit.com/articles/article.aspx?p=1404056

Larry: Comment refactorer "Design Patterns"?

Erich: Nous avons fait cet exercice en 2005. Voici quelques notes de notre session. Nous avons constaté que les principes de conception orientés objet et la plupart des modèles n'avaient pas changé depuis. Nous voulions modifier la catégorisation, ajouter de nouveaux membres et supprimer certains modèles. La discussion a principalement porté sur la modification de la catégorisation et en particulier sur les modèles à supprimer.

En discutant des modèles à abandonner, nous avons constaté que nous les aimions toujours tous. (Pas vraiment - je suis en faveur de laisser tomber Singleton. Son utilisation est presque toujours une odeur de design.)

Alors, voici quelques-uns des changements:

• Interprète et poids mouche doivent être placés dans une catégorie distincte que nous avons appelée "Autre / Composé", car ce sont vraiment des animaux différents des autres modèles. La méthode Factory serait généralisée à Factory.
• Les catégories sont: principales, créatives, périphériques et autres. Le but ici est de souligner les motifs importants et de les séparer de ceux qui sont moins utilisés.
• Les nouveaux membres sont les suivants: Objet Null, Objet Type, Injection de dépendance et Objet / Interface d'extension (voir "Objet d'extension" dans Langages de configuration de la conception de programme 3, Addison-Wesley, 1997).
• Ce sont les catégories:
  • Noyau: composite, stratégie, état, commande, itérateur, proxy, méthode du modèle, façade
  • Creational: Usine, Prototype, Constructeur, Injection de Dépendances
  • Périphérique: Fabrique abstraite, visiteur, décorateur, médiateur, objet type, objet nul, objet d'extension
  • Autre: Flyweight, interprète

Les modèles actuels du livre sont parfois vraiment utiles, mais ce ne sont en réalité que des exemples d'un outil plus puissant que le livre vous donne: une compréhension approfondie du moment et du lieu où il est préférable de couper le code monolithique en parties indépendantes séparées et régulées par une interface .

Lorsque vous apprenez cette compétence, vous réalisez que vous n'avez pas besoin de vous souvenir des détails exacts de chaque modèle, car vous pouvez toujours découper la solution que vous implémentez de la manière qui convient le mieux à son objectif. Donc, l'idée d'écrire de plus en plus de modèles semble très académique et inutile.

Je pensais donc que le nombre de modèles de conception connus et documentés augmenterait considérablement.

Cela ne s'est pas passé Plus de 20 ans après la publication du livre GoF, l'article de Wikipedia ne contient que 12 motifs supplémentaires, dont la plupart sont beaucoup moins populaires que les originaux. (Je n'ai pas inclus les modèles de concurrence ici car ils couvrent un sujet spécifique.)

Le livre GoF et Wikipedia ne sont pas la seule source de modèles de conception connus. Si vous recherchez simplement des "modèles de conception" sur Amazon.com, vous obtenez des centaines de livres (essayez cette recherche ). Je suppose qu'ils ne listent que le motif le plus connu de l'article de Wikipedia .

Le problème n'est donc pas qu'il n'y a pas suffisamment de modèles de conception documentés. Au contraire, il y en a tellement que personne ne peut les mémoriser tous et la plupart des programmeurs n'en reconnaissent que quelques-uns. La grande promesse d'un langage de modèle commun s'effondre à ce stade.

Il y a probablement beaucoup de structures auxquelles on n'a pas encore pensé. Tant que les personnes développent des logiciels, il faudra relever des défis de conception. Certains de ces problèmes pourraient bien être résolus en utilisant de nouveaux modèles intelligents que d'autres pourraient utiliser.

Les langages de programmation se sont développés et ont progressé pour résumer les motifs les plus couramment utilisés. Ces modèles existent toujours dans la conception des langues. Donc, ils peuvent être ignorés aujourd'hui, mais cela ne les rend pas sans importance.

La connaissance de la construction d’une maison devient-elle soudainement sans importance une fois que nous avons des robots qui peuvent le faire pour nous? Je dirais non, ce n'est pas. C’est moins pertinent, bien sûr - et probablement moins gratifiant à étudier, car la demande a fortement chuté et personne ne l’étudie.

Donc non, je ne crois pas que l'espace de modèle comme vous l'appelez a été épuisé. Comme une autre réponse l'a souligné, il est probable que ce soit infini. Mais à mesure que la demande de conception de systèmes diminue, à mesure que nous augmentons la hauteur de notre tour d'abstraction et la puissance de nos langages de programmation, de moins en moins de personnes qui s'installent sur les niveaux supérieurs s'intéresseront aux détails de la construction de la tour. .

Les motifs sont infinis. Vous pouvez modifier chaque motif ou mélanger pour faire apparaître de nouveaux motifs. Les motifs d’intégration d’entreprise sont également bien définis. pour chaque domaine, les modèles évoluent et ils changent également pour un langage expressif comme python ou scala.