¿Qué paradigma es mejor para el diseño y análisis de algoritmos? ¿Qué es más rápido? Porque tengo una asignatura llamada Diseño y Análisis de Algoritmos en la universidad y tengo un límite de tiempo para los programas. ¿OOP es más lento que la programación de Procedimiento? ¿O la diferencia de tiempo no es grande?OOP vs PP para los algoritmos
Existen algoritmos IMO separados del problema OO o PP.
Ni OO ni PP son 'lentos', ya sea en el tiempo de diseño o en el rendimiento del programa, son enfoques diferentes.
Para diseño, análisis y desarrollo: definitivamente OOP. Fue inventado solemnemente para beneficio de los diseñadores y desarrolladores. Para la ejecución del tiempo de ejecución del programa: a veces PP es más eficiente, pero a menudo el compilador reduce OOP a PP simple, haciéndolos equivalentes.
La diferencia (en tiempo de ejecución) es marginal en el mejor de los casos.
Tenga en cuenta que hay un factor más importante que el rendimiento puro: OOP proporciona al programador mejores medios para organizar su código que da como resultado programas bien estructurados, comprensibles y más confiables (menos errores).
Creo que Functional Programming produciría una implementación más limpia de los algoritmos.
Habiendo dicho eso, no debería ver mucha diferencia en cualquier enfoque que tome. Un algoritmo puede expresarse en cualquier lenguaje o paradigma de desarrollo.
actualización: (siguientes comentarios)
programación funcional Al parecer hace no se presta a la implementación de algoritmos, así como pensé que fuere. Tiene otras fortalezas y lo mencioné principalmente por completo, ya que la pregunta solo mencionaba OOP (programación orientada a objetos) y PP (programación de procedimientos).
Supongo que la diferencia no es lo suficientemente grande como para preocuparse, y el límite de tiempo debería permitir el uso de un lenguaje más lento, ya que el algoritmo utilizado sería lo importante. El propósito del límite de tiempo debe ser la OMI para llegar a evitar el uso de, por ejemplo, a (n) algoritmo O cuando hay un O (n log n)
de programación orientado a objetos abstrae muchos detalles de bajo nivel de el programador. Se ha diseñado con el objetivo
programación de procedimiento no tiene muchas abstracciones como objetos, métodos, funciones virtuales etc.
Así, hablando de la velocidad: un avezado experto que conoce el funcionamiento interno de cómo un sistema orientado a objetos funcionará puede escribir una programa que funciona igual de rápido
Dicho esto, la ventaja de velocidad lograda mediante el uso de PP sobre OOP será muy marginal. Todo se reduce a la forma en que puede escribir programas cómodamente.
EDIT:
Una anécdota interesante viene a la mente: en el Microsoft Foundation Classes, paso de mensajes de un objeto a otro se puso en práctica el uso de macros que parecían BEGIN_MESSAGE_MAP() y END_MESSAGE_MAP(), y la razón era que era más rápido que usar funciones virtuales.
Este es un caso donde los desarrolladores de la biblioteca han usado OOP, pero han eludido a sabiendas un cuello de botella de rendimiento.
el enlace débil es simplemente su conocimiento - con qué lenguaje & paradigma se siente más cómodo. use
La programación orientada a objetos no es particularmente relevante para los algoritmos. La programación procedimental que necesitará, pero en lo que respecta a los algoritmos, la programación orientada a objetos es solo otra forma de empaquetar la programación de procedimientos. Tiene métodos en lugar de funciones y clases en lugar de registros/estructuras, pero la única diferencia relevante es el despacho en tiempo de ejecución, y eso es solo una forma declarativa de manejar una decisión en tiempo de ejecución que podría haberse manejado de otra manera.
La programación orientada a objetos es más relevante para la escala más grande - patrones de diseño, etc. - mientras que los algoritmos son más relevantes para la escala más pequeña que implica un pequeño número (a menudo solo uno) de procedimientos.
Absolutamente. OO es más sobre la estructura del diseño de la aplicación que cualquier otra cosa. – kyoryu
Para que el código de escritura sea fácil y menos propenso a errores, necesita un lenguaje que admita Generics, como C++ con STL o Java con Java Collections Framework. Si está implementando un algoritmo contra una fecha límite, puede ahorrar tiempo al no proporcionarle a su algoritmo una interfaz O-O o genérica agradable, por lo que el código que usted escribe es completamente de procedimiento.
Para una mayor eficiencia en el tiempo de ejecución, probablemente sea mejor que escriba todo en C de procedimiento; vea, por ejemplo, los ejemplos en "La práctica de la programación", pero llevará mucho más tiempo escribir, y es más probable que cometa errores. Esto también asume que todos los componentes básicos que necesita están disponibles en su versión más actualizada y eficiente desde el C de procedimiento, lo que es una suposición en estos días. Lo más probable es que el uso de STL o JFC en la práctica le ahorrará tiempo de CPU y tiempo de desarrollo.
En cuanto a los lenguajes funcionales, recuerdo que los entusiastas de la programación funcional oyentes señalaron cuán fáciles de usar eran sus lenguajes que la competencia, y luego observar que los miembros de la clase que elegían un lenguaje funcional seguían teniendo dificultades cuando los que escribían en Fortran 77 había terminado y continuaba dibujando gráficos del rendimiento de su programa. Veo que los reclamos de la comunidad de programación funcional no han cambiado. No sé si la realidad subyacente sí.
Estoy completamente en desacuerdo con la afirmación de "tomar más tiempo para escribir y más probabilidades de cometer errores" al referirse a C. Depende mucho de lo que estamos hablando. OOP ofrece grandes beneficios al escribir grandes aplicaciones de usuario con mucha interacción del usuario donde los datos/entrada son dinámicos y desconocidos (uso de genéricos). Pero para muchos otros sistemas, escribir en vainilla C es más limpio, más fácil, más rápido y menos propenso a errores. Especialmente en sistemas integrados. – Awaken
@Awaken - en contexto, estoy de acuerdo. Pedagicamente, sin embargo, gran parte de C es C++ válido, por supuesto, por lo que puede escribir C++ como si fuera C, pero aún tener esa herramienta adicional disponible cuando sea necesario. C++ no es Java: no tiene que envolver todo en una clase, no obtiene el despacho en tiempo de ejecución por defecto, etc. etc. – Steve314
@mcdowella - Hay algunos buenos lenguajes funcionales impuros sólidos.Haskell es "puro" y bastante bueno, pero yo diría que Haskell es impuro debido a las mónadas, y si bien la idea es muy interesante, me ha llegado a desagradar el código pseudoimperativo monádico que se traduce en funcional puro solo para ser traducido de nuevo a imperativo, con dos capas de abstracción filtrada entre la fuente imperativa y la máquina imperativa. OMI el kit de herramientas funcional es extremadamente bueno, pero también se necesita el conjunto de herramientas imprescindible. Además, los lenguajes funcionales tardan un poco en acostumbrarse. La familiaridad es la clave. – Steve314
Steve314 lo dijo bien. OOP trata más sobre los patrones de diseño y la organización de grandes aplicaciones. También le permite tratar mejor con las incógnitas, lo cual es ideal para las aplicaciones de los usuarios. Sin embargo, para analizar algoritmos, lo más probable es que piense funcionalmente sobre lo que quiere hacer. En ese caso, me quedaría con PP más simple y no intentaré crear un diseño completamente OO, cuando te preocupes por el algoritmo. Me gustaría trabajar con C o Matlab (dependiendo de cuán intensivo sea el algoritmo matemático). Solo mi opinión al respecto.
una vez adaptado el algoritmo de búsqueda Knuth-Morris-Pratt cadena para que yo pudiera tener un objeto que tomaría un carácter a la vez y devolver un estado de coincidencia/no coincidencia. No fue una traducción directa.
No estoy de acuerdo. Los algoritmos son fundamentalmente sobre * cómo * haces algo.La afirmación estándar sobre programación funcional es que usted especifica * qué * quiere, * no * cómo lo hace. En particular, las actualizaciones in situ son esenciales para muchos algoritmos. Con la programación funcional, básicamente terminas intentando * implicar * el algoritmo que necesitas y esperando que el compilador/optimizador tome nota de la implicación. – Steve314
Por ejemplo, durante años, toda la comunidad de programación funcional falló completamente al detectar que la implementación funcional normal del tamiz de eratostenos (un algoritmo muy simple y bien entendido) simplemente * no era * el tamiz o eratostenes en absoluto y tenía completamente la complejidad equivocada. Cuando miles de personas inteligentes no se dan cuenta de que un algoritmo simple no es lo que dice ser, usted sabe que no tiene una manera clara o clara de describir los algoritmos. – Steve314
Durante décadas (de hecho, hasta hoy), toda la comunidad de programación procedural no pudo detectar que la implementación normal de procedimientos de la aritmética entera (una aritmética muy simple y bien entendida) simplemente no era una aritmética entera y tenía el mal resultados. Cuando decenas de millones de personas inteligentes no se dan cuenta de que una aritmética simple no es lo que dice ser, usted sabe que no tiene una manera clara o clara de describir la aritmética. Por cierto: la mayoría de los tamices que he visto estaban equivocados, independientemente de si se implementaron funcional, procedimental, OO, lógica, ... –