Empecé a leer el libro de patrones de diseño de GoF. Algunos patrones parecen muy similares con solo pequeñas diferencias conceptuales.
¿Piensas en los muchos patrones que algunos no son necesarios en un lenguaje dinámico como Python (por ejemplo, porque están sustituidos por una función dinámica)?
Peter Norvig demuestra que 16 de los 23 patrones de diseño encontrados en el libro de GOF son invisibles o más simples en idiomas dinámicos (Se enfoca en Lisp y Dylan).
Desde que mencionaste Python, hay una buena presentación de Alex Martelli sobre el tema. También relacionado con Python, hay una bonita publicación de blog que demuestra patrones de diseño en Python idiomático .
También mantengo un repositorio de github con implementaciones (por otras personas) de los patrones de diseño más comunes en Python .
No se necesitan patrones de diseño. En cualquier idioma.
Tiendo a encontrar un montón de código escrito por personas que leen sobre los patrones de diseño y luego piensan que deberían usarlos por todos lados. El resultado es que el código real se entierra bajo toneladas de interfaces, envolturas y capas y es bastante difícil de leer. Ese es un enfoque incorrecto para los patrones de diseño.
Los patrones de diseño existen para que tenga un repertorio de expresiones idiomáticas útiles cuando se encuentre con un problema. Pero nunca debe aplicar ningún patrón antes de identificar el problema. Mantenlo simple y estúpido siempre debe ser el principio de gobierno superior.
También ayuda pensar en los patrones de diseño como un concepto para pensar en el problema en lugar de escribir un código específico para escribir. Y acerca de gran parte de la plantilla como solución alternativa a Java que carece de funciones libres y objetos de función estándar que utiliza en la mayoría de los otros lenguajes que los tienen (como Python, C #, C ++, etc.).
Podría decir que tengo un patrón de visitante, pero en cualquier idioma con funciones de primera clase será solo una función que toma una función. En lugar de la clase de fábrica, normalmente tengo una función de fábrica. Podría decir que tengo una interfaz, pero luego solo son un par de métodos marcados con comentarios, porque no habría ninguna otra implementación (por supuesto, en python, una interfaz siempre es solo comentarios, porque está tipificada). Todavía hablo del código como el uso del patrón, porque es una forma útil de pensarlo, pero en realidad no escribo todas las cosas hasta que realmente lo necesite.
Aprende todos los patrones como conceptos . Y olvídate de las implementaciones específicas. La implementación varía, y debería variar, en el mundo real, incluso solo en Java.
Resumen patrón de fábrica no es necesario en lenguaje tipográfico como Python, ya que es Prácticamente incorporado al lenguaje.
El único que viene a la mente es el patrón Singleton.
Ya que Python no te obliga a usar clases para todo , puedes usar una estructura de datos global. Esa estructura de datos global podría ser administrada por una instancia, pero no tiene que controlar la creación de instancias de esa clase, simplemente cree la instancia en la importación y déjela así.
En su mayoría, Singletons en python se reemplaza con un módulo. Los módulos en python son por su propia naturaleza Singletons; El intérprete de Python los crea una sola vez.
Todos los demás patrones en Design Patters que he usado en Python en un momento u otro, y encontrarás ejemplos de ellos en la biblioteca estándar de Python y en Python.
Los patrones de diseño son para el programador, no para el lenguaje. Los programadores tienden a usar patrones que les ayudan a entender el problema en cuestión. Ningún patrón de diseño es estrictamente necesario, pero puede ser útil para ayudar a simplificar lo que está tratando de hacer.
Python y Duck Typing específicamente, proporcionan un final en torno a muchos patrones y prácticas comunes, y muchas de las restricciones impuestas por algunos patrones (privacidad, inmutabilidad, etc.) solo se aplican en la medida en que el programador no lo acepta. para romperlos Pero aún así, sí funcionan mientras el programador siga el ritmo. Una puerta sigue siendo una puerta, incluso si está enmarcada por paredes imaginarias.
Python se considera un lenguaje "multi-paradigma"; Puedes usar los patrones que quieras. Esto es intencional. Proporciona jerarquías de clases complejas, por ejemplo, aunque son completamente innecesarias y un poco artificiales. Pero para algunas personas, esa abstracción en particular es útil. No porque el problema lo exija, sino porque lo hace el programador. Así que ahí tienes.
El libro original de "Patrones de diseño" documentó y nombró algunos modismos comunes útiles en lenguajes imperativos orientados a objetos, como C ++ y Smalltalk. Pero Smalltalk es un lenguaje de tipo dinámico, por lo que no puede ser estrictamente una cuestión de ser dinámico.
Sin embargo, la respuesta a su pregunta sigue siendo "sí": algunos de estos patrones de diseño serán irrelevantes para los idiomas modernos de tipo dinámico. Más generalmente, habrá diferentes patrones de diseño en diferentes idiomas, especialmente en diferentes tipos de idiomas.
Para reiterar: un "patrón de diseño" es simplemente un nombre para un lenguaje de programación: una solución común para un problema frecuente. Diferentes idiomas requieren diferentes expresiones idiomáticas, porque lo que es un problema para un idioma puede ser trivial para otro. En este sentido, los patrones de diseño tienden a señalar las debilidades en los idiomas a los que se aplican.
Por lo tanto, puede buscar otras características que hagan que los lenguajes dinámicos modernos (o los antiguos como Lisp) sean más potentes, lo que hace que algunos de estos patrones de diseño clásicos sean irrelevantes.
Los patrones de diseño son formas de resolver problemas particulares. Si no se resuelve un problema, el patrón de resolución no tiene uso.
La gente está tratando de adaptar los patrones de diseño en todas partes como si fuera una buena práctica tener patrones de diseño en su proyecto. Eso es al revés. ¿Te encuentras con un problema que se puede resolver con un patrón de fábrica? Guay. Adáptalo. No busque su código e intente encontrar el lugar adecuado para implementar un singleton (o fábrica, o fachada, o lo que sea ...).
¿Quizás Python tiene sus propios patrones de diseño no disponibles para las personas de Java y .NET (debido a la naturaleza de estos idiomas)?
Yo diría que los patrones siempre dependen del lenguaje. Que la mayoría de los patrones de Python se parecen a los definidos en GoF es debido a la OOP de Python, lo que se dice OOP no es como OOP (no hay dos idiomas que definen los objetos y su manipulación al 100%).
Por lo tanto, no hay duda de que algunos patrones no serán aplicables "como están", algunos podrían no tener sentido y hay algunos patrones que podrían ser significativos para Python.
Para volver exactamente a su pregunta: los patrones solo son necesarios si los necesita . No tiene que usarlos si no los necesita (como ya dijo Jan Hudec).
Además, hay muchos más patrones que los mencionados en GoF. Consulte en wikipedia otros patrones
Lea otras preguntas en las etiquetas design-patterns python