oop - programacion - programación orientada a objetos vs programación estructurada
Programación funcional vs programación orientada a objetos (4)
He estado expuesto principalmente a la programación de OO hasta ahora y estoy ansioso por aprender un lenguaje funcional. Mis preguntas son:
- ¿Cuándo elige la programación funcional sobre la orientada a objetos?
- ¿Cuáles son las definiciones típicas de problemas donde la programación funcional es una mejor opción?
¿Cuándo elige la programación funcional sobre el objeto orientado?
Cuando anticipas un tipo diferente de evolución de software:
Los lenguajes orientados a objetos son buenos cuando tienes un conjunto fijo de operaciones en cosas , y a medida que tu código evoluciona, principalmente agregas cosas nuevas. Esto se puede lograr agregando nuevas clases que implementan métodos existentes, y las clases existentes se quedan solas.
Los lenguajes funcionales son buenos cuando tienes un conjunto fijo de cosas , y a medida que tu código evoluciona, principalmente agregas 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 quedan 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 cosa a un programa funcional puede requerir editar muchas definiciones de función para agregar un nuevo caso.
Este problema ha sido bien conocido durante muchos años; en 1998, Phil Wadler lo apodó el "problema de expresión" . Aunque algunos investigadores piensan que el problema de la expresión se puede abordar con características de lenguaje tales como mixins, una solución ampliamente aceptada aún no ha llegado a la corriente principal.
¿Cuáles son las definiciones típicas de problemas donde la programación funcional es una mejor opción?
Los lenguajes funcionales sobresalen en la manipulación de datos simbólicos en forma de árbol. Un ejemplo favorito son los compiladores, donde los lenguajes fuente e intermedios cambian rara vez (principalmente las mismas cosas ), pero los escritores de compiladores siempre están agregando nuevas traducciones y mejoras de código u optimizaciones (nuevas operaciones en cosas). La compilación y la traducción más generalmente son "aplicaciones asesinas" para los lenguajes funcionales.
Si está en un entorno muy concurrente, entonces la programación funcional pura es útil. La falta de estado mutable hace que la concurrencia sea casi trivial. Ver Erlang.
En un lenguaje multiparadigm, es posible que desee modelar algunas cosas funcionalmente si la existencia de un estado mutable es un detalle de implementación, y por lo tanto, FP es un buen modelo para el dominio del problema. Por ejemplo, vea la lista de comprensión en Python o std.range en el lenguaje de programación D. Estos están inspirados en la programación funcional.
La programación orientada a objetos ofrece:
- Encapsulacion, a
- control de mutación del estado interno
- Limitar el acoplamiento a la representación interna.
- Subtipo, permitiendo:
- Sustitución de tipos compatibles (polimorfismo).
- un medio bruto de compartir implementación entre clases (herencia de implementación)
La programación funcional, en Haskell o incluso en Scala, puede permitir la sustitución a través de un mecanismo más general de clases de tipo. El estado interno mutable está desanimado o prohibido. También se puede lograr la encapsulación de la representación interna. Ver Haskell vs OOP para una buena comparación.
La afirmación de Norman de que "Agregar un nuevo tipo de cosa a un programa funcional puede requerir editar muchas definiciones de función para agregar un nuevo caso". Depende de qué tan bien el código funcional ha empleado clases de tipo. Si la concordancia de patrones en un tipo de datos abstracto en particular se propaga a través de una base de código, ciertamente sufrirá este problema, pero tal vez sea un diseño pobre para empezar.
EDITADO Se eliminó la referencia a las conversiones implícitas al discutir las clases de tipos. En Scala, las clases de tipos están codificadas con parámetros implícitos, no conversiones, aunque las conversiones implícitas son otro medio para lograr la sustitución de tipos compatibles.
No necesariamente tienes que elegir entre los dos paradigmas. Puede escribir software con una arquitectura OO utilizando muchos conceptos funcionales. FP y OOP son de naturaleza ortogonal .
Tomemos por ejemplo C #. Se podría decir que es principalmente POO, pero hay muchos conceptos y construcciones de PF. Si considera a Linq , las construcciones más importantes que permiten que Linq exista son de naturaleza funcional: expresiones lambda .
Otro ejemplo, F #. Se podría decir que es principalmente FP, pero hay muchos conceptos y construcciones de POO disponibles. Puede definir clases, clases abstractas, interfaces, lidiar con la herencia. Incluso puede usar la mutabilidad cuando hace que su código sea más claro o cuando aumenta dramáticamente el rendimiento.
Muchos lenguajes modernos son multi-paradigmas.
Lecturas recomendadas
Como estoy en el mismo barco (fondo de POO, aprendizaje de FP), le sugiero algunas lecturas que realmente aprecié:
Programación funcional para el desarrollo diario de .NET , por Jeremy Miller. Un gran artículo (aunque con un formato pobre) que muestra muchas técnicas y ejemplos prácticos y reales de FP en C #.
Programación funcional del mundo real , por Tomas Petricek. Un gran libro que trata principalmente de los conceptos de PF, tratando de explicar qué son, cuándo deberían usarse. Hay muchos ejemplos tanto en F # como en C #. Además, el blog de Petricek es una gran fuente de información.