Interesante visión de la OLP
Esto no es un problema de la POO, sino de su aplicación, y más aún de quienes la aplican. Son los que sienten...
entusiasmo, incluso el éxtasis de que con la ayuda de la POO se puede escribir increíblemente
código increíblemente complicado (e incluso competir en él :). Se sienten una élite especial.
Incluso han inventado su propio "gran libro" que leen y leen y leen pero no pueden
pero no pueden leerlo. Se llama "Patrones de Diseño" - en lenguaje humano
se traduce como "El arte definitivo de escribir código difuso, borroso y confuso". Sin embargo, si.
es una cosa muy, muy genial, increíblemente simplificadora y
simplifica y simplifica la vida.
Ahí tienes, siempre sospechoso)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Debes entender que lo más probable es que estos artículos estén escritos por personas que no están familiarizadas con la FP y sus confusos ganchos, que pueden incluir 20 pestañas....
La FP dura es otra cosa. Entonces se empieza a pensar en el laconismo y la conveniencia de la POO, se puede declarar parte de la funcionalidad por adelantado y así ..... En esencia, la similitud de uno con el otro. Eso es sólo que tales artículos son a menudo escritos por personas que han dominado sólo el código de procedimiento - y esto no es ni siquiera cerca de FP, así que si usted no sabe lo que los ganchos y el uso vivo de ella, no FP está fuera de la cuestión
Además, muchos de los "lenguajes moribundos" enumerados en el artículo soportan la funcionalidad completa de FP y OOP, ¿por qué deberían morir? Y un par de ellos son los mejor pagados de la CEISe trata más bien de una "espaguetización" en OOP, sin pensar en absoluto en "ahogarse" en FP. En mi opinión, el paradigma procedimental es realista y más eficiente en cuanto a recursos que la POO.
¿sólo que el código en sí es más largo en oop? bueno, sí, hay un constructor y en algunos casos el código suele ser más largo en él.... técnicamente, la implantación de FP debería ser más eficiente para la generación de código máquina.... pero el código no se simplifica y es imposible hacer envoltorios normales en cuanto a la tipificación...
hoy en día, a menudo se puede encontrar una mezcla de uno y otro - las formas no interfieren entre sí
¿sólo que el código en sí es más largo en oop? bueno, sí, hay un constructor y en algunos casos el código suele ser más largo en él.... técnicamente, la implantación de FP debería ser más eficiente para la generación de código máquina.... pero el código no se simplifica y es imposible hacer envoltorios normales en cuanto a la escritura...
Hoy en día, a menudo es posible ver una mezcla de lo uno y lo otro.
Sin OOP y FP todo funciona más fácil y rápido (sí, sin "bellezas", paneles, etc.), pero a veces es difícil entender incluso tu propio código)
Sin OOP y FP, todo funciona más fácil y rápido (sí, sin "bellezas", paneles, etc.), pero a veces es difícil entender incluso tu propio código).
Primero domina uno u otro, o mejor ambos, y luego decide qué prefieres. Y con un planteamiento como el de ahora con el tiempo te convertirás en Fedoseev que está de acuerdo con todo lo que no entiendes (es decir, con casi todo).
Qué reacción tan destructiva ante el tema y qué discusión tan destructiva. Dígame un seguidor de la programación procedimental cómo evitar la "espaguetización" en la POO, cómo parsear y si tiene sentido utilizar el "espagueti" de otro.
Al fin y al cabo, lo que resulta es que la POO sirve sobre todo para la legibilidad y la programación en equipo, es decir, para los grandes proyectos. Un Asesor Experto que negocia un símbolo a su gráfico con el control del riesgo máximo del saldo / fondos en la cuenta, bueno, no puede ser llamado un gran proyecto - es suficiente y más rentable en la memoria / velocidad - la programación de procedimiento.
Preguntas:
- desventajas/desventajas de la POO (como imperativo) desde la experiencia personal
- desventajas/desventajas de la PF (como declarativa) a partir de la experiencia personal.
Y una opinión sobre las perspectivas es, por supuesto, interesante, especialmente en la dirección de la computación paralela. No veo que tenga sentido tocar el tema de la cuántica.
Dígame, como programador procedimental, cómo evitar la "espaguetización" en la POO
La receta se da en el artículo citado: esfuérzate por escribir funciones deterministas.
¿Cómo se desmonta y tiene sentido utilizar los "espaguetis" de otra persona?
Buen código, sí, pero no espaguetis.
Después de todo lo que se consigue, OOP es sobre todo para la legibilidad y la programación en equipo, es decir, para los grandes proyectos.
Sí.
Un EA que opere con un símbolo a un gráfico del que está adherido con el máximo control de riesgo de los fondos del balance/cuenta, bueno, no se puede llamar un gran proyecto - por lo que la programación procedimental es suficiente y más rentable en términos de memoria/velocidad.
Para viajar a Australia, es más conveniente utilizar un avión (OOP), para viajar a una ciudad vecina, basta con un coche o incluso una bicicleta (PP). Sólo hay que elegir el medio más conveniente para lograr el objetivo.
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Ahí tienes, siempre sospechoso)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23