La literatura de programación OO está llena de patrones de diseño. La mayoría de los libros sobre programación orientada a objetos dedican un capítulo o dos para diseñar patrones como fábricas y decoradores. Entonces, ¿cuáles son los patrones equivalentes en los lenguajes funcionales y por qué nadie ha escrito un libro sobre ellos todavía? ¿Hay algo especial en los lenguajes funcionales que evita la necesidad de patrones de diseño?
OO y la programación funcional son dos paradigmas de programación muy diferentes, y los patrones de diseño (DP) son una parte importante del diseño y la programación de OO. Los DP no tienen ese rol en la programación funcional.
Incluso se podría decir que los DP no son necesarios en la programación funcional, no hay comezón para lo que se puede curar.
Uno podría argumentar que los patrones de diseño son un signo de características faltantes en un lenguaje de programación.
Peter Norvig encontró que 16 de los 23 patrones en Design Patterns book son " ya sea invisible o simple r" en Lisp o Dylan.
"Muchos patrones implican una orientación a objetos o un estado más generalmente mutable, por lo que pueden no ser aplicables en lenguajes de programación funcionales, en los que los datos son inmutables o se tratan como tales". - enlace
Jeremy Gibbons está escribiendo el libro. Hasta que termine, puedes leer su blog, Patrones en la programación funcional . Recomienda leer sus publicaciones de la más antigua a la más reciente.
Examine también sus publicaciones . Cubre los patrones de Gang of Four en Patrones de diseño como programas genéricos de tipo de datos de orden superior y describe los patrones de programación con ecuaciones recursivas en Origami Programming (se pliega y despliega).
El hecho simple es que muchos patrones OO se considerarían expresiones idiomáticas en lenguajes funcionales (especialmente los patrones GoF originales). Por ejemplo, el patrón Iterator (integrado a lenguajes como C # ahora) simplemente no es necesario en un Lisp o ML que tenga operadores de secuencia.
Muchos de los patrones que utilizamos en los sistemas O-O están ahí para ayudarnos a eliminar los "elementos no esenciales" para que podamos centrarnos en codificar objetos. En otras palabras, los patrones son soluciones para las partes no interesantes de la aplicación. Debemos aprovechar los patrones para abordar las necesidades comunes que se han resuelto anteriormente (como los patrones en Fowlers Patterns of Enterprise Application Architecture para tratar con cosas como la transmisión de bases de datos, o xUnit Patterns para impulsar sus pruebas de unidad) para que podamos centrarnos en agregar valor comercial para la aplicación.
Estoy seguro de que más allá de las características específicas de los patrones GoF, hay patrones de diseño que también serán aplicables a la programación funcional. La cosa es que O-O es el paradigma dominante. Escribir un libro de patrones dirigido a desarrolladores funcionales ... bueno, francamente, no obtendrá una luz verde de un editor. A eso se reduce. No hay suficiente mercado para que los patrones funcionales tengan un número significativo de libros dedicados al tema.
Una buena charla (~ 45 min) sobre este tema por Stuart Sierra:
No necesariamente vinculante y autoritario, pero reconocí algunos de sus ejemplos de mi propia experiencia en el uso de FP para el análisis de datos.
Ejemplos escritos en Clojure, pero probablemente aplicables a cualquier lenguaje de PF. Los nombres que da a los patrones que cubre son:
Si realmente estás interesado en aprender los patrones de diseño, no busques más que Haskell. Si se toma el tiempo para aprenda el idioma de la manera más difícil que encontrará y siéntase cómodo con la mayoría de los patrones fundamentales: están integrados en el lenguaje.
No te saltes las mónadas. Hay un montón de explicaciones muy largas y se necesitan algunas ideas para asimilarlas, pero si sigues conectándote, al final te darás cuenta y te sorprenderás de la cantidad de patrones de diseño. construir sobre esta abstracción / interfaz.
Una vez que hayas asimilado a Haskell, tendrás suficiente arsenal de PF a tu disposición para ser peligroso. El punto es, manténgalo en ello hasta que lo obtenga. No hay atajos.
En la medida en que la metodología de diseño para FP es diseñar sus tipos para reflejar con precisión el espacio del problema y la implementación debe seguir automáticamente, el equivalente en FP de un libro sobre patrones de diseño es algo así como Estructuras de datos puramente funcionales .
Lea otras preguntas en las etiquetas design-patterns functional-programming books
