Programación funcional vs. OOP [cerrado]


93

Últimamente he escuchado mucho hablar sobre el uso de lenguajes funcionales como Haskell. ¿Cuáles son algunas de las grandes diferencias, ventajas y desventajas de la programación funcional frente a la programación orientada a objetos?


27
Uno no rechaza a otro.
mbq

1
@mbq Entiendo que no son mutuamente excluyentes, pero solo quería tratar de comprender mejor la diferencia de los dos enfoques.
GSto

Gran pregunta Me he estado preguntando sobre esto también.
JohnFx

La programación funcional y la programación orientada a objetos son ortogonales entre sí. Puedes tener ambos en el mismo idioma. Ejemplos: Scala, F #, OCaml, etc. ¿Quizás quiso decir funcional versus imperativo, como sugirió Jonas ?
missingfaktor

44
La verdadera respuesta es: no hay "versus" entre ellos. Echa un vistazo a esta pregunta en StackOverflow .
missingfaktor

Respuestas:


67

Yo diría que es más programación funcional vs Imperativo de programación .

La mayor diferencia es que la programación imperativa se trata del flujo de control, mientras que la programación funcional se trata del flujo de datos . Otra forma de decirlo es que la programación funcional solo usa expresiones, mientras que en la programación imperativa se usan tanto expresiones como declaraciones .

Por ejemplo, en la programación imperativa, las variables y los bucles son comunes cuando se maneja el estado, mientras que en la programación funcional el estado se maneja a través del paso de parámetros, lo que evita los efectos secundarios y las asignaciones.

Seudocódigo imperativo para una función para calcular la suma de una lista (la suma se mantiene en una variable):

int sumList(List<int> list) {
    int sum = 0;
    for(int n = 0; n < list.size(); n++) {
        sum = sum + list.get(n);
    }

    return sum;
}

Seudocódigo funcional para la misma función (la suma se pasa como parámetro):

fun sumList([], sum) = sum
 |  sumList(v::lst, sum) = sumList(lst, v+sum)

Recomiendo la presentación Efectos de domesticación con programación funcional de Simon Peyton-Jones para una buena introducción a los conceptos funcionales.


12
Debe mencionar que la versión funcional es recursiva en la cola y, por lo tanto, está optimizada para evitar desbordamientos de pila. (Algunas personas pueden ver la recursión y pensar que la programación funcional es mala debido a eso)
alternativa el

3
+1 para describir el aspecto más importante de imperativo versus funcional: flujo de control vs flujo de datos. Una cosa que debo agregar es que el paradigma funcional y el paradigma OO no son mutuamente excluyentes; puede usar el paradigma OO para modelar cómo interactúa el objeto (datos) y el paradigma funcional para transformar (manipular) ese objeto.
Lie Ryan

1
Curiosamente, puede modelar datos como control y control como datos también para mezclarlos. FP puede usar flechas y funciones de primer orden para pasar el flujo de control y manipularlo como datos. OOP usa varios patrones de diseño para usar objetos para alterar el flujo de control.
CodexArcanum

Creo que también vale la pena señalar que la diferencia principal no es que escribes el mismo programa sino que haces tus llamadas de método recursivo de cola de bucles. es mucho más grande que eso
sara

Su ejemplo funcional hace uso de la coincidencia de patrones de parámetros. Eso no es exclusivo de la programación funcional, programas similares pueden usar mónadas e incluso construcciones imperativas sin necesidad de formular cada algoritmo iterativo como un algoritmo recursivo.
Dai

16

La programación funcional se basa en un modelo declarativo y tiene sus raíces en el cálculo lambda. Ofrece muchos conceptos geniales que se pueden tomar prestados de lenguajes más imperativos como C ++ y C #.

Algunos ejemplos incluyen transparencia referencial, funciones lambda, funciones de primera clase, evaluación perezosa e impaciente e inmutabilidad.

Si por nada más, aprender programación funcional es útil para los conceptos que contiene. Cambiará la forma de programar y pensar acerca de la programación. Y supongo que en el futuro la programación funcional será tan importante como lo ha sido la programación orientada a objetos.

Para comenzar, puede elegir usar un lenguaje funcional puro como Haskell, o puede usar uno híbrido como F # .

La mayoría de las buenas universidades cubrirán la programación funcional y si vas a la escuela, te sugiero que tomes ese curso.


¿Cuáles son algunas de las grandes diferencias, ventajas y desventajas de la programación funcional frente a la programación orientada a objetos?

La programación bien orientada a objetos es buena porque le permite modelar su problema complejo en jerarquías para que pueda simplificar el problema. Pero se vuelve muy difícil cuando comienzas a considerar la programación de subprocesos múltiples al usar objetos mutables. En tales casos, debe utilizar mucho los objetos de sincronización y es casi imposible perfeccionar una aplicación grande.

Ahí es donde entra la programación funcional. Debido a cosas como la inmutabilidad, la programación funcional realmente simplifica los programas de subprocesos múltiples. Hace que sea casi trivialmente fácil paralelizar algo cuando se sabe que, dada la entrada X a una función, siempre generará Y. También se sabe que una variable (o valor en la programación funcional) no puede cambiar a mitad de uso desde otro hilo.


2
Para ser claros, Scheme no es en absoluto un lenguaje funcional puro.
Jonathan Sterling

55
Su segundo último párrafo es completamente bs. OO no plantea ningún problema en subprocesos múltiples, la mutabilidad sí. Parece que confunde la programación imperativa con la programación orientada a objetos. ¿Es ese el caso?
missingfaktor

55
@missingfaktor: No, no estoy confundiendo los conceptos. Un objeto generalmente tiene accesores, modificadores, miembros de datos y funciones miembro. Sí, no todos los objetos necesitan tener modificadores y puede implementarlos como inmutables. Pero si observa cualquier programa OO arbitrario, es casi seguro que tendrá varios objetos que tienen modificadores y aún así son utilizados por múltiples hilos. Es decir, en un paradigma OOP es bastante raro tener todo inmutable.
Brian R. Bondy

Debería leer las respuestas a esta pregunta: stackoverflow.com/questions/3949618/fp-and-oo-orthogonal/…
missingfaktor

Consulte también la respuesta de Frank Shearar aquí: programmers.stackexchange.com/questions/12423/…
missingfaktor

8

(Esta respuesta está adaptada de una respuesta a una pregunta cerrada en StackOverflow ).

Una de las grandes diferencias entre la programación funcional y la programación orientada a objetos es que cada uno es mejor en un tipo diferente de evolución del software:

  • Los lenguajes orientados a objetos son buenos cuando tiene un conjunto fijo de operaciones sobre cosas y, a medida que su código evoluciona, agrega principalmente cosas nuevas. Esto se puede lograr agregando nuevas clases que implementen métodos existentes, y las clases existentes se dejan solas.

  • Los lenguajes funcionales son buenos cuando tiene un conjunto fijo de cosas y, a medida que su código evoluciona, agrega principalmente nuevas operaciones en cosas existentes. Esto se puede lograr agregando nuevas funciones que computan con los tipos de datos existentes, y las funciones existentes se dejan solas.

Cuando la evolución va por el camino equivocado, tienes problemas:

  • Agregar una nueva operación a un programa orientado a objetos puede requerir editar muchas definiciones de clase para agregar un nuevo método.

  • Agregar un nuevo tipo de cosas a un programa funcional puede requerir editar muchas definiciones de funciones para agregar un nuevo caso.

Este problema se conoce desde hace muchos años; en 1998, Phil Wadler lo denominó el "problema de expresión" . Aunque algunos investigadores piensan que el problema de la expresión puede abordarse con características del lenguaje como los mixins, una solución ampliamente aceptada aún no ha llegado a la corriente principal.


Me encanta tu respuesta, palabra de sabiduría aquí. Lo conocí hace unos meses y solo pasé 30 minutos buscándolo específicamente, ya que no lo había marcado. Solo la mejor explicación sobre OOP vs FP para aquellos que entienden la ventaja de comprender conceptos en lugar de técnicas. El artículo sobre el problema de la expresión también es fantástico. Muchas gracias por compartir su opinión, su respuesta es muy subestimada en mi opinión.
tobiak777

4

No hay real versus. Pueden ser perfectamente complementarios. Hay lenguajes FP, que admiten OOP. Pero las comunidades difieren en la forma en que manejan la modularidad.

Los usuarios de lenguajes FP tienden a lograr modularidad a través de leyes matemáticas. Y prefiera pruebas para demostrar el cumplimiento de sus leyes.

En imperativo, los usuarios de OOP tienden a capturar el comportamiento del objeto en los casos de prueba, que se pueden volver a ejecutar si el objeto ha cambiado y lograr así la modularidad.

Es solo un aspecto pequeño, pero creo que vale la pena mencionarlo.


2

Una analogía:

Te entregaron una solicitud de empleo. Complete su nombre, información de contacto e historial de trabajo. Cuando haya terminado, ya no tendrá una solicitud en blanco.

Ahora imagine que antes de escribir lo superpone con una hoja transparente de celofán. Tu escribes tu nombre. Agregas otra hoja de celofán. Usted escribe su información de contacto. Más celofán. Tú escribes tu historia laboral. Cuando haya terminado, todavía tiene la aplicación en blanco intacta. También tiene tres hojas de celofán, cada una de las cuales ha capturado el efecto de un único cambio discreto.

El primero (OOP) adopta la idea de cambiar las cosas en su lugar, mientras que el segundo (FP) lo evita. Ambos son paradigmas de gestión estatal. Ambos pueden, utilizando diferentes estrategias, capturar el efecto de completar una solicitud de empleo. OOP cambia el instrumento de inicio directamente, mientras que FP superpone lo que vino antes para efectuar la aparición del cambio .


hermosa analogia, gracias !! ¿Le importaría (si es posible) extender esta analogía con pros y contras en estos dos enfoques?
Rahul Agarwal
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.