Existe-t-il des modèles de conception inutiles dans les langages dynamiques comme 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 ne sont pas nécessaires 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 conception 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 mentionné Python, il y a un Nice présentation par Alex Martelli sur le sujet. Également lié à Python, il y a un article de blog Nice montrant six modèles de conception en Python idiomatique .
Je garde également un référentiel github avec des 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 code écrit par des gens qui lisent sur les modèles de conception et 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 des modèles de conception.
Les modèles de conception existent afin que vous ayez un répertoire d'idiomes utiles à portée de main lorsque vous rencontrez un problème. Mais vous ne devez jamais appliquer de modèle avant d'identifier le problème. Keep It Simple Stupid devrait toujours être le principe directeur supérieur.
Cela aide également à penser les modèles de conception comme un concept pour réfléchir au problème plutôt que du code passe-partout spécifique à écrire. Et une grande partie du passe-partout comme solution de contournement à Java manquant de fonctions gratuites et d'objets de fonction standard que vous utilisez dans la plupart des autres langages qui en ont (comme Python, C #, C++, etc.).
Je pourrais dire que j'ai un modèle de visiteur, mais dans n'importe quelle 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 pourrais dire que j'ai une interface, mais ce ne sont que quelques méthodes marquées de commentaires, car il n'y aurait pas d'autre implémentation (bien sûr dans python une interface est toujours juste des commentaires, parce qu'il est de type canard) .Je parle toujours du code comme utilisant le motif, parce que c'est une façon utile d'y penser, mais ne saisissez pas vraiment tous les trucs avant d'en avoir vraiment besoin.
Apprenez donc tous les modèles comme concepts. Et oubliez les implémentations spécifiques. L'implémentation varie et devrait varier dans le monde réel, même uniquement en Java.
Modèle d'usine abstrait n'est pas nécessaire dans un langage de type canard tel que Python, car il est pratiquement intégré au langage.
Le seul qui me vient à l'esprit est le motif Singleton.
Puisque Python ne vous oblige pas à utiliser des classes pour tout, vous pouvez simplement utiliser une structure de données globale à la place. Cette structure de données globale pourrait = être géré par une instance, mais vous n'avez pas à contrôler l'instanciation de cette classe, il vous suffit de créer l'instance à l'importation et de la laisser à cela.
Généralement, les singletons en python sont remplacés par un module. Les modules en python sont par nature des singletons; les python l'interprète les crée une seule fois.
Tous les autres modèles de Design Patters que j'ai utilisés dans Python à un moment ou à un autre, 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.
Python, et le typage de canard en particulier, permettent de mettre fin à de nombreux modèles et pratiques courants, et de nombreuses restrictions imposées par certains modèles (confidentialité, immuabilité, etc.) ne s'appliquent que dans la mesure où le programmeur accepte de ne pas les briser. . Mais encore, ils font fonctionnent aussi longtemps que le programmeur joue. 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 les modèles que vous souhaitez. C'est intentionnel. Il prévoit 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 particulière est utile. Non pas parce que le problème l'exige, mais parce que le programmeur le fait. Alors voilà.
Le livre original "Design Patterns" a documenté et nommé certains idiomes communs 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 d'être 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 typés dynamiquement. Plus généralement, il y aura différents modèles de conception dans différentes langues, en particulier dans différentes sortes de langues.
Pour réitérer: un "modèle de conception" est simplement un nom pour un idiome de programmation: une solution courante à 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 à signaler des faiblesses dans les langues auxquelles ils s'appliquent.
Ainsi, vous pouvez rechercher d'autres fonctionnalités qui rendent les langages dynamiques modernes (ou anciens comme LISP) plus puissants, rendant certains de ces modèles de conception classiques non pertinents.
Les modèles de conception sont des moyens de résoudre des problèmes particuliers. Si un problème n'est pas rencontré, le modèle de résolution n'a aucune utilité.
Les gens essaient d'adapter les modèles de conception partout comme si c'était une bonne pratique d'avoir des modèles de conception dans votre projet. C'est l'inverse. Vous rencontrez un problème qui peut être résolu avec un modèle 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, ou une façade, ou autre ...).
Peut-être Python a ses propres modèles de conception non disponibles pour Java et les personnes .NET (en raison de la nature de ces langages))?
Je dirais que les modèles dépendent toujours de la langue. Que la plupart des modèles python ressemblent à ceux définis dans GoF, c'est à cause des OOP de Python, cela étant dit OOP est pas comme OOP (aucun langage ne définit les objets et leur manipulation à 100%).
Il n'y a donc aucun doute que certains modèles ne seront pas applicables "tels quels", certains pourraient ne pas avoir de sens et il y a des modèles qui n'ont 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'êtes pas obligé de les utiliser si vous n'en avez pas besoin (comme l'a déjà dit Jan Hudec).
En outre, il existe beaucoup plus de modèles que ceux mentionnés dans le GoF. Voir dans wikipedia autres modèles