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

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

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 .

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.

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.

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.

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

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.

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

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