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

144

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?

design-patterns object-oriented-design Frank Puffer
la source
49
Les motifs sont partout mais ils sont souvent utilisés de manière robotique et sans goût. Pour cette raison, je pense que l’idée du catalogue de modèles est devenue moins populaire.
Usr
6
Espace de conception? Quelqu'un amène Mark Rosewater ici, stat!
CorsiKa
16
Martin Fowler a publié en 2003, Patterns of Enterprise Application Architecture, documentant environ 50 motifs, dont beaucoup sont encore parfaitement reconceptibles et bien utilisés, par exemple, "Data Mapper", "Plugin", "Lazy Load", "Service Layer", etc.
Brian Rogers
2
Explorer l’espace de tous les modèles possibles équivaudrait à ne pas explorer l’espace des modèles possibles. Vous pouvez faire de tout un motif. Si vous faites de tout un motif, rien n’est un motif, car le mot perd sa signification.
Espérons-
4
@ BradThomas: Bien sûr, comme pour les questions les plus intéressantes, les gens ont tendance à avoir une certaine opinion. Mais les opinions reposent au moins en partie sur des faits, et j’ai trouvé dans les réponses à cette question de nombreux faits intersectoriels qui aideraient moi-même et, espérons-le, les autres à repenser leurs opinions et à en arriver à des plus justifiées.
Frank Puffer

Réponses:

165

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:

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.

Michael Borgwardt
la source
50
Opinion controversée: l’usine abstraite
dégage
66
Opinion controversée, peut-être, mais une opinion tellement importante à exprimer. Les modèles de design risquent de devenir un exemple des nouveaux vêtements de l'empereur, où nous avons tous peur de nous demander s'ils sont utiles. Bien joué.
David Arno
18
@MetaFightControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();
CorsiKa
11
" L'intérêt des modèles de conception est d'améliorer la communication entre les développeurs " Je pensais que les modèles de conception étaient destinés à résoudre des problèmes couramment rencontrés (et assez souvent de manière indépendante) par les développeurs. Les normes améliorent la communication et, en raison des fluctuations (schémas résultant de problèmes XY, les schémas étant considérés comme anti-schémas), beaucoup ne considèrent pas les schémas de conception comme des standards. Les modèles de conception sont efficaces pour identifier le manque de fonctionnalités de langage et je pense que les concepteurs de langage mettent en œuvre ces solutions avant qu'elles ne deviennent des modèles de conception. Ne prenez pas ma parole pour un fait cependant
Vince Emigh
11
@ChrisW Je ne vois pas ce que vous voulez dire ... Comme je l'ai dit, le GoF a tenté de surmonter les faiblesses de OO, et plus particulièrement celles de C ++ 98, car c'était leur langage de prédilection avec Smalltalk. Ils ont en fait écrit: "Le choix du langage de programmation est important car il influence le point de vue de chacun. Nos modèles reposent sur des fonctionnalités de langage de niveau Smalltalk / C ++, et ce choix détermine ce qui peut et ne peut pas être implémenté facilement."
Shautieh
108

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.

Robert Harvey
la source
40
"Les modèles de conception (au sens de GoF) n'ont qu'un but: compenser les lacunes du langage de programmation que vous utilisez." Je continue à entendre cela, mais je ne l'ai toujours pas vu justifié. Chaque justification supposée ne fait que pointer une série de modèles qui sont plus faciles à mettre en œuvre dans les langues avec certaines fonctionnalités - généralement Visiteur et peut-être Singleton - et la grande majorité de ces modèles restent intacts, ce qui implique simplement qu'ils peuvent également être redondants. meilleures langues. Mais comment savons-nous? Quelle fonctionnalité de langue rend Observer non pertinent? Chaîne de responsabilité? Composite?
Jules
56
@Jules Les fonctions de première classe éliminent à elles seules une grande partie d'entre elles, y compris la chaîne de responsabilité (il s'agit simplement de la composition d'une liste de fonctions). La programmation réactive fonctionnelle élimine le motif Observer. Le motif composite n'est qu'une définition moins rigoureuse des monoïdes. Les langages avec classes de type et l'accent mis sur les lois algébriques fournissent des outils puissants pour travailler avec des monoïdes. Je pourrais en énumérer beaucoup plus, mais vous voyez l'idée.
Jack
12
@Jules: Je crois que l'itérateur du livre original GoF a énuméré l'itérateur en tant que modèle, mais maintenant, sa transformation en fonctionnalité de langage est pratiquement terminée dans tous les langages distants de programmation orientée objet.
Kevin
9
@RubberDuck, comment le modèle est-il déjà mis en œuvre pour le rendre obsolète? C'est toujours le modèle de conception en cours d'implémentation. Différents ensembles de fonctionnalités de langage peuvent conduire à différentes implémentations du modèle, mais le modèle lui-même est toujours là. Les modèles sont là pour faciliter la communication en donnant des noms aux stratégies récurrentes couramment utilisées. Au cas où, les classes .NET sont appelées, ObservableSomething<T>ce qui facilite la compréhension de leur objectif, car elle utilise le nom de modèle communément connu. Un motif est une idée, pas une implémentation exacte.
null
29
@Jules: Qu'est-ce qu'un programme? Une solution à un problème récurrent. Qu'est-ce qu'un motif de conception? Une solution à un problème récurrent. Pourquoi n'est-ce pas un programme? Parce que nous ne pouvons pas l'exprimer en tant que programme. Ergo, un motif de conception est une solution à un problème récurrent qui devrait plutôt être un programme, pas un motif de conception, mais ne peut pas être un programme, car le langage n’est pas assez expressif pour exprimer le programme. Exemple: il n'y a pas si longtemps, "Appel de sous-programme" était un motif de conception! De nos jours, c'est une fonctionnalité linguistique.
Jörg W Mittag,
61

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.
Jerry Coffin
la source
2
"... mais ce qui rend un programme intéressant, c'est sa différence avec les autres programmes." Je suis tout à fait d’accord, mais pour cela il faut d’abord avoir la même partie, peut-être qu’elles ne diffèrent que par un aspect trivial. Si vous vous détendez un peu du besoin de nommer et d’identifier des schémas, je suis convaincu que l’on en voit presque tous. C'est juste qu'ils ne viennent presque jamais sous leur forme pure mais sont toujours plus ou moins adaptés au problème à résoudre.
Trilarion
5
Très bonne réponse.
Robert Harvey
4
@Trilarion: Oh, je réalise que ces parties du code doivent être écrites. Ils ressemblent un peu, par exemple, aux pneus de votre voiture. Vous avez pratiquement besoin de pneus pour conduire - mais la plupart des gens connaissent encore à peine la marque de pneus de leur voiture. Cela leur demande d'apprendre une terminologie particulière pour un pneu à rainures diagonales asymétriques. Qui sait? Ceux-ci auraient peut-être sauvé ma vie une fois, mais je ne passe toujours pas ma vie à apprendre des noms pour eux.
Jerry Coffin
3
@DavidRicherby: D'accord, utilisons une version "analogique" de l'analogie. Est-il important que John qui conçoit les pneus pour Goodyear utilise un mot pour désigner ce type de groove, alors que Pierre qui travaille pour Michelin utilise un mot totalement différent? Est-il important que l’un utilise un mot ne faisant référence qu’au sillon, mais l’autre un mot désignant un pneu complet avec des rainures horizontales d’un côté et des rainures diagonales de l’autre?
Jerry Coffin
2
@immibis: Je dirais que la plupart du temps oui, ils ont échoué. Je dirais qu'il y a moins d'une demi-douzaine de schémas reconnus par les programmeurs. Singleton est bien connu, mais ne s'applique que rarement (au mieux). Le nom "Factory" était d'usage courant bien avant l'apparition de "motifs" (je me souviens de son utilisation à la fin des années 1970 ou au début des années 1980). Les motifs étaient censés former un vocabulaire, mais actuellement ils ressemblent beaucoup à mon vocabulaire grec - assez pour (éventuellement) avoir des ennuis, mais certainement pas assez pour ordonner un menu, encore moins avoir une conversation enrichissante.
Jerry Coffin
35

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.

Siphor
la source
2
Personnellement, j'aime beaucoup cette idée. Mais alors, le code devrait être lisible par les humains et les gens comme des modèles. Les motifs nous aident à trouver notre chemin. Supprimer tous les modèles de notre code le rendra illisible.
Frank Puffer
2
@Frank Je pense que PG tire son origine du fait qu'un motif est une "odeur" d'une fonction sous-jacente que vous pouvez résumer, et le fait que vous ne l'ayez pas extrait dans une fonction ou une macro est la cause de la répétition - comme si vous n'aviez pas de String.replacefonction, vous pouvez l'imaginer en tant que motif, mais il est préférable de l'écrire une fois plutôt que de continuer à la réimplémenter. Acceptez le fait que si vous ne nommez pas ces choses correctement, cela rendra la lecture plus difficile, mais si c'est bien fait, le code lit de manière plus déclarative IMO (par exemple, le getOrElsestyle de l'option monads vs null checking)
anotherdave
11
La citation de Paul Graham parlait de garder vos solutions au sec, ce qui est différent de l'idée de "modèle" du GoF. L'idée du GoF était de donner des noms aux solutions couramment utilisées. Nous le faisions déjà bien avant que le GoF publie son livre. Par exemple, je peux dire à mon collègue que je vais utiliser une file d'attente et ce dernier sait immédiatement de quoi je parle sans que je doive expliquer en détail son fonctionnement ou son fonctionnement. Mais voir l'excellente réponse de Michael Borgwardt ci-dessus.
Salomon Slow
10
À mon avis, cette réponse ne comprend pas ce que sont les modèles. Un modèle de conception est une solution souvent rencontrée à un problème commun. Ce n'est pas une duplication de code. Dites, prenez un itérateur. Vous résolvez le problème de l’abstraction du conteneur afin de pouvoir examiner les éléments qu’il contient, quel que soit son contenu. Ainsi, vous créez une classe d'itérateur qui le fait pour chacun de vos conteneurs et leur faites implémenter une interface commune. Quoi résumer ici? Un itérateur est déjà une abstraction. Et, bien sûr, il est implémenté différemment pour tous les conteneurs, donc pas de duplication de code.
Malcolm
3
La partie essentielle de la citation de Graham est souvent que je génère à la main l’expansion d’une macro que j’ai besoin d’écrire. Ceci fait spécifiquement référence aux macros Lisp. Il n'y a qu'une quantité d'abstraction que l'on peut faire sans macros.
Bart van Nierop
13

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?).

qwerty_so
la source
1
Oui, les modèles ne peuvent fonctionner que s’ils ne sont pas trop nombreux. Mais pourquoi les GoF sont-ils toujours les plus populaires? Certains d'entre eux sont maintenant considérés comme des anti-patrons par beaucoup de gens (Singleton, Builder, etc.). Cela devrait faire place à de nouveaux modèles plus utiles sans augmenter le nombre total.
Frank Puffer
2
Je suppose que c'est comme les 10 commandements. La source est à seulement 2 caractères (GOF, GOE, DIEU) xD
qwerty_so
9
Oui, et il semble parfois que l'ingénierie logicielle moderne se rapporte au GoF, tout comme les scolastiques médiévaux se rapportent à Aristote.
Frank Puffer
11

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.

Jared Smith
la source
10

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.

utilisateur207421
la source
Est-ce toujours triste si cela aboutissait à cette discussion (et tout ce que cela implique)
r3wt
1
@ r3wt Non sequitur. Ce que j’ai dit est triste, c’est la faiblesse de l’industrie des technologies de l’information à penser que chaque nouveau développement va devenir la solution miracle, et accessoirement à la destruction de ses propres travaux antérieurs.
user207421
2
regardez-le sous un angle différent. Ce n'est pas triste pour moi de lire votre réponse, d'apprendre à ne pas répéter l'erreur. alors ce que vous prenez pour acquis est en réalité très utile pour les autres.
R3WT
6

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.

ChrisW
la source
Oui, vous pouvez trouver des descriptions de centaines de motifs si vous les recherchez. Mais aucun de ceux-ci ne semble être aussi populaire que ceux du GoF.
Frank Puffer
C’est parce que j’ai aimé lire le livre GoF que j’ai lu davantage (les livres) lorsqu’ils ont été publiés (plus tard).
ChrisW
1
@ FrankPuffer Je parie que les modèles sont populaires, même si les noms ne le sont pas.
départ du
5

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".

Ian
la source
3

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
Akuhn
la source
Pourquoi me votez-vous? S'il vous plaît expliquer dans un commentaire afin que je puisse améliorer la réponse.
Akuhn
3

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.

lud1977
la source
Bon point, cependant je doute que beaucoup de gens comprennent le livre (ou les modèles en général) de cette façon.
Frank Puffer
@ lud1977 si nous n'enregistrons pas l'histoire, qu'est-ce qui empêche l'avenir de tomber dans les mêmes pièges? ainsi, il doit toujours être enregistré. ce n'est pas inutile.
R3WT
2

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.

iluwatar
la source
-1

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. .

Tim
la source
-2

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.

Marut Singh
la source