Existe-t-il des modèles de conception inutiles dans des langages dynamiques tels que Python?

98

J'ai commencé à lire le livre de modèles de conception par le GoF. Certains modèles semblent très similaires avec seulement des différences conceptuelles mineures.

Pensez-vous que parmi les nombreux modèles, certains sont inutiles dans un langage dynamique comme Python (par exemple, parce qu’ils sont remplacés par une fonctionnalité dynamique)?

design-patterns python

— Gerenuk
source

1

Une sorte de question intéressante, car elle implique que le choix de la langue peut remplacer efficacement les constructions de code.

— joshin4colours

3

Pas une réponse, mais une pertinence - je pensais que les modèles de conception GoF étaient aussi pertinents pour certains principes généraux qui peuvent en être déduits que pour les modèles spécifiques. Je ne parle pas de l'idée d'un modèle (bien que ce soit certainement important), mais plus encore de l'autorisation d'utiliser des classes d'une manière qui viole les principes naïfs de la POO. Par exemple, il existe de nombreux modèles dans lesquels "la forme" ne "dessine" pas, ou du moins, délègue un aspect du travail à un autre objet. Je pense que cette leçon est importante dans toutes les langues compatibles avec la programmation orientée objet.

— Steve314

Question très intéressante. Je voudrais pouvoir +5 au lieu de +1.

— MathAttack

1

Coup d' oeil à ASLO sont de conception Patterns Caractéristiques linguistiques manquantes et Modèles de conception sont manquantes fonctionnalités du langage plus à c2. Ce n'est même pas un problème de «langage dynamique». L'exemple le plus simple est le modèle d'itérateur qui est trivial en python, perl (et même en Java - non dynamique).

92

Peter Norvig démontre que 16 des 23 modèles de design trouvés dans le livre GOF sont invisibles ou plus simples dans les langages dynamiques (il se concentre sur Lisp et Dylan).

Puisque vous avez parlé de Python, Alex Martelli a fait une présentation intéressante sur le sujet. Également lié à Python, il y a un article de blog montrant six modèles de conception en Python idiomatique .

Je conserve également un référentiel github avec les implémentations (par d'autres personnes) des modèles de conception les plus courants en Python .

— Sakis
source

Génial! Ce serait une tache sur la réponse :) J'aurais aimé que tout le monde comprenne la question aussi clairement.

— Gerenuk

2

Selon Norvig, 2 sur 16 (interpréteur et itérateur) sont "soit invisibles, soit plus simples" en raison de macros (que Python n'a pas).

— MJS

1

ce n'est pas clair pour moi que tous ces modèles ne sont pas nécessaires parce que lisp est dynamique mais plutôt à cause d'autres fonctionnalités telles que le fait d'être un langage fonctionnel fort

— jk.

@mjs Les itérateurs sont une fonctionnalité intégrée de Python.

— Sakisk

1

Cette grande réponse peut être même légèrement améliorée en changeant les légendes de lien un peu de sens montre , présentation et dépôt - ils sont beaucoup mieux alors ici , mais vous savez ... :-)

— Loup

59

Aucun modèle de conception n'est nécessaire. Dans n'importe quelle langue.

J'ai tendance à rencontrer beaucoup de codes écrits par des personnes qui lisent des motifs de conception et qui pensent ensuite qu'ils devraient les utiliser partout. Le résultat est que le code réel est enterré sous des tonnes d'interfaces, de wrappers et de couches et est assez difficile à lire. C'est une mauvaise approche pour concevoir des modèles.

Les motifs de conception existent de sorte que vous disposiez d'un répertoire d'idiomes utiles lorsque vous rencontrez un problème. Mais vous ne devez jamais appliquer aucun modèle avant d’identifier le problème. Keep It Simple Stupid devrait toujours être le principe directeur supérieur.

Il est également utile de penser aux modèles de conception comme à un concept de réflexion sur le problème plutôt qu’à un code passe-partout spécifique à écrire. Et à propos de la plupart des problèmes rencontrés en tant que solution de contournement de Java, il manque des fonctions libres et des objets de fonction standard que vous utilisez dans la plupart des autres langages qui en disposent (comme Python, C #, C ++, etc.).

Je pourrais dire que j'ai un modèle de visiteur, mais dans toute langue avec des fonctions de première classe, ce sera juste une fonction prenant une fonction. Au lieu de la classe d'usine, je n'ai généralement qu'une fonction d'usine. Je dirais peut-être que j'ai une interface, mais il ne s'agit que de deux méthodes marquées avec des commentaires, car il n'y aurait pas d'autre implémentation (bien sûr, en python, une interface est toujours composée de commentaires, car elle est typée). Je parle toujours du code comme utilisant le motif, parce que c'est une façon utile de penser à cela, mais ne tapez pas tout ce qui est écrit avant d'en avoir vraiment besoin.

Alors, apprenez tous les modèles en tant que concepts . Et oubliez les implémentations spécifiques. La mise en œuvre varie et devrait varier dans le monde réel, même en Java.

— Jan Hudec
source

28

Votre déclaration préliminaire simplifie à l'extrême. Il est vrai que les motifs ont un coût, il ne faut donc pas les utiliser aveuglément, mais pour le plaisir de le faire. Mais au bon endroit, ils peuvent être d'une grande aide. Et oui, ils sont spécifiques à la langue - certains schémas ne sont pas nécessaires dans certaines langues car la langue elle-même prend en charge une meilleure approche. Mais c'est encore assez loin de votre revendication d'ouverture.

— Péter Török le

2

Btw Visitor n'est pas entièrement remplacé par des fonctions d'ordre supérieur. Il s'agit d'une solution permettant d'implémenter la double distribution dans un langage qui ne la prend pas en charge de manière native (telle que C # et C ++). (Et il devrait en effet être utilisé avec parcimonie - je le considère comme l'un des schémas les plus coûteuses et les plus coûteuses, dont l'utilisation est à mon humble avis si difficile à justifier que je ne l'ai jamais utilisé moi-même jusqu'à présent.)

— Péter Török

14

Eh bien, vous n'avez jamais besoin d' un motif. Ce qu'il vous faut, c'est résoudre un problème . Si vous ne connaissez pas de modèle, vous pouvez toujours le résoudre, cela demandera plus de réflexion et vous pourrez proposer une solution qui correspond à un modèle ou à une autre. Connaître les modèles facilite les choses.

— Jan Hudec

3

@Gerenuk: Oui, mais le fait est que les modèles ne sont pas spécifiques à la langue, ils le sont pour votre tête. Vous trouvez souvent que certains motifs sont réalisés beaucoup plus facilement et utilisent différents outils en python, mais le même concept existe généralement.

— Jan Hudec le

4

@ PéterTörök: le visiteur n'est remplacé par rien. Le point est que le même concept peut être mis en œuvre en utilisant des outils différents dans des cas différents, mais je le considère toujours comme le même modèle.

— Jan Hudec

13

Le modèle de fabrique abstraite n’est pas nécessaire dans un langage typé «canard» tel que Python, car il est pratiquement intégré au langage.

— vartec
source

10

eh bien, vous avez encore besoin d'usines différentes. Vous n'avez simplement pas besoin de la définition d'interface.

— Stefano Borini

1

Si vous avez un cours, vous avez déjà une usine. Les classes sont des objets de première classe et peuvent être transmises partout et simplement appelées pour créer un objet (contrairement à Java). Vous n'avez pas besoin de créer autre chose. Si vous voulez quelque chose qui ne soit pas le constructeur par défaut, créez simplement un lambda / callable quelconque qui enveloppe le constructeur d’une manière ou d’une autre.

— spookylukey

13

Le seul qui me vienne à l’esprit est le modèle Singleton.

Comme Python ne vous oblige pas à utiliser des classes pour tout , vous pouvez simplement utiliser une structure de données globale. Cette structure de données globale peut être gérée par une instance, mais vous n'avez pas à contrôler l'instanciation de cette classe, vous créez simplement l'instance lors de l'importation et vous en restez là.

Généralement, les singletons en python sont remplacés par un module. Les modules en python sont par nature Singletons; l'interprète python les crée une fois et une fois seulement.

Tous les autres modèles de Design Patters que j'ai utilisés à un moment ou à un autre dans Python, et vous en trouverez des exemples dans la bibliothèque standard Python et dans Python lui-même.

— Martijn Pieters
source

2

N'est-ce pas réellement un anti-modèle de nos jours?

— Den

16

Le Singleton est un anti-modèle . Dans toutes les langues. Il a été créé pour résoudre plusieurs problèmes non liés et ne correspond pas à l'un ou l'autre (remarque, même Java a des membres statiques, qui existent une fois par classe, vous n'avez donc pas besoin d'une instance pour cela).

— Jan Hudec le

1

Et en Python, nous ne l’avons jamais dérangé car il n’ya jamais eu de problème à résoudre.

— Martijn Pieters

1

"Python ne vous oblige pas à utiliser des objets pour tout" Pas vrai. Ce n'est tout simplement pas odieux comme en Java, mais tout de même en Python, tout est objet. Même module est un objet.

— vartec

3

@Darthfett: Je sais bien comment ça lenmarche. Guido a fait un choix explicite ici . Mon but est de montrer que Python n’est pas un langage purement POO; c'est un langage pragmatique. Je l'aime comme ça.

— Martijn Pieters

8

Les modèles de conception sont pour le programmeur, pas pour la langue. Les programmeurs ont tendance à utiliser des modèles qui les aident à comprendre le problème à résoudre. Aucun modèle de conception n'est strictement nécessaire, mais il peut être utile pour simplifier ce que vous essayez de faire.

Le typage Python et canard en particulier fournit une fin à beaucoup de schémas et de pratiques communs, et beaucoup de restrictions imposées par certains schémas (confidentialité, immuabilité, etc.) ne tiennent que dans la mesure où le programmeur accepte de ne pas les briser. . Mais encore, ils ne travaillent aussi longtemps que le programmeur joue le jeu. Une porte est toujours une porte, même si elle est encadrée par des murs imaginaires.

Python est considéré comme un langage "multi-paradigme"; vous pouvez utiliser ce que vous voulez. C'est intentionnel. Il fournit des hiérarchies de classes complexes, par exemple, même si elles sont complètement inutiles et un peu artificielles. Mais pour certaines personnes, cette abstraction est utile. Pas parce que le problème l'exige, mais parce que le programmeur le fait. Alors voilà.

— tylerl
source

C'est certainement intéressant. Alors, quels modèles en particulier voulez-vous qu'on puisse oublier, car il existe de meilleurs moyens en Python?

— Gerenuk

4

Le livre original "Design Patterns" documentait et nommait des expressions courantes utiles dans les langages impératifs orientés objet tels que C ++ et Smalltalk. Mais Smalltalk est un langage typé dynamiquement, il ne peut donc pas être strictement question de dynamique.

Cependant, la réponse à votre question est toujours "oui": certains de ces modèles de conception ne seront pas pertinents pour les langages modernes à typage dynamique. Plus généralement, il y aura différents modèles de conception dans différentes langues, en particulier dans différents types de langues.

Pour réitérer: un "modèle de conception" est simplement le nom d'un idiome de programmation: une solution commune à un problème fréquemment rencontré. Différentes langues nécessitent des idiomes différents, car ce qui pose problème pour une langue peut être trivial pour une autre. En ce sens, les modèles de conception ont tendance à souligner les faiblesses des langages auxquels ils s'appliquent.

Vous pouvez donc rechercher d'autres fonctionnalités qui rendent les langages dynamiques modernes (ou des langages anciens comme Lisp) plus puissants, rendant certains de ces modèles de conception classiques inutiles.

— venir tempête
source

1

Les modèles de conception sont des moyens de résoudre des problèmes particuliers. Si un problème n'est pas rencontré, sa résolution ne sert à rien.

Les gens essaient d'adapter les modèles de conception partout, comme s'il s'agissait d'une pratique exemplaire d'intégrer des modèles de conception à votre projet. C'est l'inverse. Vous rencontrez un problème qui peut être résolu avec un motif d'usine? Cool. Adaptez-le. Ne cherchez pas votre code et essayez de trouver le bon endroit pour implémenter un singleton (ou une usine, une façade, etc.).

Peut-être que Python a ses propres modèles de conception non disponibles pour les personnes Java et .NET (en raison de la nature de ces langages)?

— Andrzej Bobak
source

1

Je dirais que les modèles dépendent toujours de la langue. La plupart des motifs Python ressemblent à ceux définis dans le GoF. C’est à cause de la programmation orientée objet de Python que cela signifie qu’OOP n’est pas semblable à la programmation orientée objet (aucun langage ne définit les objets et leur manipulation à 100%).

Il ne fait donc aucun doute que certains modèles ne seront pas applicables "en l'état", d'autres n'auront peut-être aucun sens et certains modèles pourraient n'avoir de sens que pour Python.

Pour revenir exactement à votre question: Les modèles ne sont nécessaires que si vous en avez besoin . Vous n'avez pas besoin de les utiliser si vous n'en avez pas besoin (comme Jan Hudec l'a déjà dit).

De plus, il existe beaucoup plus de modèles que ceux mentionnés dans le GoF. Voir dans Wikipedia d' autres modèles

— estani
source