El blog ha citado usted exagera su reclamo un poco. FP no eliminar la necesidad de patrones de diseño. El término "patrones de diseño" simplemente no es ampliamente utilizado para describir la misma cosa en FP idiomas. Pero ellos existen. Los lenguajes funcionales tienen un montón de mejores reglas de la práctica de la forma "cuando encontramos un problema X, utilice el código que se parece a Y", que es básicamente lo que es un patrón de diseño.
Sin embargo, es correcto que la mayoría de la programación orientada a objetos específicos de los patrones de diseño son bastante irrelevantes en los lenguajes funcionales.
No creo que se debe ser especialmente controvertido decir que los patrones de diseño , en general, sólo existen para cubrir las deficiencias en el lenguaje.
Y si de otro idioma puede resolver el mismo problema trivialmente, que en otro idioma no tiene necesidad de un patrón de diseño. A los usuarios de que el lenguaje puede incluso no ser conscientes de que el problema existe, porque, bueno, no es un problema en ese idioma.
Las principales características funcionales
la programación incluye funciones como
valores de primera clase, alarmada,
valores inmutables, etc. No parece
obvio para mí que OO patrones de diseño
se aproximan a cualquiera de los
características.
¿Cuál es el modelo de comandos, si no una aproximación de primera clase de las funciones? :)
En un FP de idioma, usted simplemente pasar una función como argumento a otra función.
En un lenguaje POO, tienes que envolver la función en una clase, que puede crear y, a continuación, pasar el objeto a la otra función. El efecto es el mismo, pero en la programación orientada a objetos es llamado un patrón de diseño, y se necesita de mucho más código.
Y lo que es el abstracto patrón de fábrica, si no alarmada? Pasar parámetros a una función un poco a la vez, para configurar qué tipo de valor se escupe cuando finalmente se llame.
Así que sí, varias GoF patrones de diseño son prestados redundante en FP idiomas, porque más potentes y fáciles de usar alternativas existen.
Pero, por supuesto, todavía hay patrones de diseño que son no resuelto por la FP idiomas. ¿Qué es la FP equivalente de un singleton? (Ignorando por un momento que los únicos son generalmente una terrible patrón de uso)
Y funciona en ambos sentidos. Como ya he dicho, la FP tiene sus patrones de diseño demasiado, la gente no suele pensar en ellos como tales.
Pero se puede ejecutar a través de las mónadas. ¿Qué son, si no un patrón de diseño para "tratar con el estado global"?
Ese es un problema que es tan simple en la programación orientada a objetos lenguajes que no hay equivalente patrón de diseño que existe allí.
No necesitamos un patrón de diseño para "incrementar una variable estática", o "lectura de que la toma", porque es justo lo que hacen.
En (puro) de los lenguajes funcionales, los efectos secundarios y el estado mutable es imposible, a menos que trabaje alrededor de ella con la mónada "patrón de diseño", o cualquiera de los otros métodos para permitir la misma cosa.
Además, en los lenguajes funcionales
que apoyan la programación orientada a objetos (tales como F# y
OCaml), me parece obvio que
los programadores que utilizan estas lenguas
se utilizan los mismos patrones de diseño
encuentra disponible para todos los demás la programación orientada a objetos
lenguaje. De hecho, ahora mismo yo uso F#
y OCaml todos los días, y no hay
las diferencias notables entre la
los patrones de uso en estos idiomas vs
los patrones que yo uso cuando escribo en
De Java.
Tal vez porque todavía estás pensando en imperativamente? Un montón de gente, después de lidiar con lenguajes imperativos todas sus vidas, tener un tiempo difícil renunciar a ese hábito cuando se trate de un lenguaje funcional. (He visto algunos bastante divertidos intentos de F#, donde literalmente cada función era sólo una cadena de 'vamos' declaraciones, básicamente, como si la hubiera tomado un programa en C, y sustituyen a todos los símbolos de punto y coma con el 'vamos'. :))
Pero otra posibilidad podría ser que simplemente no se han dado cuenta de que se está resolviendo los problemas de trivialmente que requeriría de patrones de diseño en un lenguaje POO.
Cuando se utiliza alarmada, o pasar una función como un argumento a otro, detenerse y pensar acerca de cómo te gustaría hacerlo en un lenguaje POO.
¿Hay alguna verdad a la afirmación de que el
la programación funcional se elimina la
necesidad de OOP, patrones de diseño?
Sí. :)
Cuando se trabaja en un FP de idioma, usted ya no necesita la programación orientada a objetos-patrones de diseño específicos. Pero usted todavía necesita algunos patrones de diseño, como MVC o no-programación orientada a objetos específicos de la materia, y que necesita una pareja de nueva FP específica de "patrones de diseño" en su lugar. Todas las lenguas tienen sus defectos, y los patrones de diseño son generalmente de cómo vamos a trabajar alrededor de ellos.
De todos modos, puede resultar interesante para probar su mano en la de "limpiador" FP idiomas, como el ML (mi favorito personal, al menos para los propósitos de aprendizaje), o Haskell, donde no se dispone de la programación orientada a objetos muleta a la que recurrir cuando te encuentras con algo nuevo.
Edición:
Como era de esperar, un par de personas que se opuso a mi definición de patrones de diseño como "reparar las deficiencias en un lenguaje", así que aquí está mi justificación:
Como ya se dijo, la mayoría de los patrones de diseño específicos de un paradigma de programación, o incluso a veces un idioma específico. A menudo, los que resuelven los problemas que sólo existen en ese paradigma (Ver mónadas de FP, o resumen de las fábricas de programación orientada a objetos).
¿Por qué no el abstracto patrón de fábrica existen en FP? Porque el problema que intenta resolver no existe.
Por lo tanto, si existe un problema en la programación orientada a objetos lenguajes, que no existe en FP idiomas, entonces es claro que es un defecto de la programación orientada a objetos lenguajes. El problema puede ser resuelto, pero su lenguaje no hacerlo, pero requiere un montón de código reutilizable para trabajar alrededor de ella. Idealmente, nos gustaría que nuestro lenguaje de programación por arte de magia hacer que todos los problemas desaparezcan. Cualquier problema que todavía existe es, en principio, una deficiencia de la lengua. ;)
