paradigms - programacion - programación funcional c#
OOP vs Programación Funcional vs Procesal (7)
Creo que a menudo no son "contra", pero puedes combinarlos. También creo que muchas veces, las palabras que mencionas son solo palabras de moda. Hay pocas personas que realmente saben lo que significa "orientado a objetos", incluso si son los más feroces evangelistas de esto.
¿Cuáles son las diferencias entre estos paradigmas de programación, y se adaptan mejor a problemas particulares o los casos de uso favorecen a los demás?
Ejemplos de arquitectura apreciados!
Creo que las bibliotecas, herramientas, ejemplos y comunidades disponibles superan por completo el paradigma en estos días. Por ejemplo, ML (o lo que sea) puede ser el último lenguaje de programación para todo propósito , pero si no puede obtener ninguna buena biblioteca para lo que está haciendo, está jodido.
Por ejemplo, si está creando un videojuego, hay más buenos ejemplos de códigos y SDK en C ++, por lo que probablemente esté mejor con eso. Para una aplicación web pequeña, hay algunos grandes frameworks de Python, PHP y Ruby que lo pondrán en marcha rápidamente. Java es una excelente opción para proyectos más grandes debido a las bibliotecas y plataformas de verificación y compilación en tiempo de compilación.
Solía ser el caso de que las bibliotecas estándar para diferentes idiomas eran bastante pequeñas y fácilmente replicadas: C, C ++, Ensamblador, ML, LISP, etc. llegaron con lo básico, pero tendían a desorientarse cuando se trataba de estandarizar las cosas. como las comunicaciones de red, el cifrado, los gráficos, los formatos de archivos de datos (incluido XML), incluso las estructuras de datos básicas, como árboles equilibrados y tablas hash, quedaron fuera.
Los lenguajes modernos como Python, PHP, Ruby y Java ahora vienen con una biblioteca estándar mucho más decente y tienen muchas bibliotecas de terceros que puede usar fácilmente, gracias en gran parte a su adopción de espacios de nombres para evitar que las bibliotecas entren en conflicto entre sí. y recolección de basura para estandarizar los esquemas de administración de memoria de las bibliotecas.
Estos paradigmas no tienen que ser mutuamente excluyentes. Si nos fijamos en Python, admite funciones y clases, pero al mismo tiempo, todo es un objeto, incluidas las funciones. Puede mezclar y combinar el estilo funcional / oop / procedural en una sola pieza de código.
Lo que quiero decir es que, en los lenguajes funcionales (al menos en Haskell, el único que estudié) ¡no hay declaraciones! Las funciones solo son permitidas una expresión dentro de ellas !! PERO, las funciones son ciudadanos de primera clase, puedes pasarlas como parámetros, junto con un montón de otras habilidades. Pueden hacer cosas poderosas con pocas líneas de código.
Mientras que en un lenguaje de procedimiento como C, la única manera de pasar funciones es mediante el uso de punteros de función, y eso solo no permite muchas tareas poderosas.
En Python, una función es un ciudadano de primera clase, pero puede contener un número arbitrario de declaraciones. Por lo tanto, puede tener una función que contiene código de procedimiento, pero puede pasarla como lenguajes funcionales.
Lo mismo ocurre con la POO. Un lenguaje como Java no le permite escribir procedimientos / funciones fuera de una clase. La única forma de pasar una función es envolverla en un objeto que implemente esa función y luego pasar ese objeto.
En Python, no tienes esta restricción.
Para GUI, diría que el Paradigma Orientado a Objetos es muy adecuado. La ventana es un objeto, los cuadros de texto son objetos y el botón Aceptar también lo es. Por otro lado, cosas como el procesamiento de cadenas se pueden hacer con mucho menos gastos generales y, por lo tanto, más sencillos con un simple paradigma de procedimientos.
No creo que sea una cuestión de idioma tampoco. Puede escribir funcional, de procedimiento o orientado a objetos en casi cualquier lenguaje popular, aunque podría ser un esfuerzo adicional en algunos.
Para responder a su pregunta, necesitamos dos elementos:
- Comprensión de las características de los diferentes estilos / patrones de arquitectura.
- Comprensión de las características de los diferentes paradigmas de programación.
Se muestra una lista de estilos / patrones de arquitectura de software en el artículo de arquitectura de software en Wikipeida. Y puedes investigar sobre ellos fácilmente en la web.
En resumen, en general, el procedimiento es bueno para un modelo que sigue un procedimiento, la POO es buena para el diseño y la funcional es buena para la programación de alto nivel.
Creo que deberías intentar leer la historia de cada paradigma y ver por qué la gente lo crea y puedes entenderlo fácilmente.
Después de comprenderlos, puede vincular los elementos de los estilos / patrones de arquitectura a los paradigmas de programación.
Todos ellos son buenos a su manera: son simplemente enfoques diferentes de los mismos problemas.
En un estilo puramente procedimental, los datos tienden a estar altamente desacoplados de las funciones que operan en él.
En un estilo orientado a objetos, los datos tienden a llevar consigo una colección de funciones.
En un estilo funcional, los datos y las funciones tienden a tener más en común entre sí (como en Lisp y Scheme), mientras que ofrecen más flexibilidad en términos de cómo se utilizan realmente las funciones. Los algoritmos también tienden a definirse en términos de recursión y composición en lugar de bucles e iteraciones.
Por supuesto, el lenguaje mismo solo influye en el estilo preferido. Incluso en un lenguaje puramente funcional como Haskell, puede escribir en un estilo de procedimiento (aunque eso es muy desalentador), e incluso en un lenguaje de procedimiento como C, puede programar en un estilo orientado a objetos (como en el GTK + y API de EFL).
Para que quede claro, la "ventaja" de cada paradigma está simplemente en el modelado de sus algoritmos y estructuras de datos. Si, por ejemplo, su algoritmo involucra listas y árboles, un algoritmo funcional puede ser el más sensible. O, si, por ejemplo, sus datos están altamente estructurados, podría tener más sentido componerlos como objetos si ese es el paradigma nativo de su idioma, o podría ser escrito tan fácilmente como una abstracción funcional de mónadas, que Es el paradigma nativo de lenguajes como Haskell o ML.
La elección de lo que usa es simplemente lo que tiene más sentido para su proyecto y las abstracciones que admite su idioma.
Uno de mis amigos está escribiendo una aplicación de gráficos usando NVIDIA CUDA . La aplicación encaja muy bien con el paradigma OOP y el problema se puede descomponer en módulos perfectamente. Sin embargo, para usar CUDA necesita usar C, que no admite la inheritance . Por lo tanto, necesitas ser inteligente.
a) Usted diseña un sistema inteligente que emulará hasta cierto punto la herencia. ¡Se puede hacer!
i) Puede usar un sistema de gancho , que espera que cada hijo C de padre P tenga una cierta anulación para la función F. Puede hacer que los niños registren sus anulaciones, que se almacenarán y llamarán cuando sea necesario.
ii) Puede usar la función de alineación de memoria de estructura para convertir a los niños en padres.
Esto puede ser bueno, pero no es fácil encontrar una solución confiable y preparada para el futuro. Pasará mucho tiempo diseñando el sistema y no hay garantía de que no tenga problemas en la mitad del proyecto. Implementar la herencia múltiple es aún más difícil, si no casi imposible.
b) Puede usar una política de nomenclatura coherente y usar el enfoque de dividir y conquistar para crear un programa. No tendrá ninguna herencia, pero como sus funciones son pequeñas, fáciles de entender y tienen un formato consistente, no las necesita. La cantidad de código que necesita escribir aumenta, es muy difícil mantenerse enfocado y no sucumbir a soluciones fáciles (hacks). Sin embargo, esta forma ninja de codificación es la forma C de codificación. Mantener el equilibrio entre la libertad de bajo nivel y escribir un buen código. Una buena forma de lograr esto es escribir prototipos utilizando un lenguaje funcional. Por ejemplo, Haskell es extremadamente bueno para los algoritmos de creación de prototipos.
Tiendo hacia el acercamiento b. Escribí una posible solución usando el enfoque a, y seré honesto, me sentí muy poco natural al usar ese código.