Interesante visión de la OLP - página 5
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Si la pregunta es a mi ejemplo - al menos ocultas la implementación (la ocultas incluso de ti mismo) - es decir, escribes sólo la lógica de los cálculos, es conveniente, es legible, te permite evitar errores lógicos
SZZY: Con respecto al comercio - escribí y todavía hago experimentos con rejillas de órdenes, donde escribo la lógica de colocar órdenes como A + B - C, donde A, B, y C - que son órdenes con parámetros predefinidos, muy útil para los algoritmos genéticos- tema interesante
Los envoltorios son una solución buena y lógica. Cuando se adapte al propósito. Y creo que los wrappers son una innovación en el lenguaje procedimental. Exactamente en el sentido de novedad y utilidad.
En cuanto a la negociación - escribí y todavía llevo a cabo experimentos con rejillas de órdenes donde escribo la lógica de colocación de órdenes como A + B - C , donde A, B y C son órdenes con parámetros predefinidos - es muy útil para los algoritmos genéticos- es un tema interesante
A, B y C con parámetros predefinidos, ¿como fenotipo para los algoritmos genéticos?
La encapsulación da libertad de nombres. Y si este problema se resuelve con la lógica del nombre. Esto, por supuesto, es costoso. entonces se puede escribir python en funciones. pero no será una solución comercializable. pero es POSIBLE.
En python, cualquier función es un objeto, al igual que una variable)
Por cierto, un ejemplo de POO continua es Python. Allí, más bien, nadie sabe que existe otra cosa que no sea OOP.
hay cierres y puedes escribir sin OOP en absoluto, al menos en el antiguo, lo que quieras.
en python, cualquier función, como una variable, es un objeto)
Lo único que puedes hacer es utilizar referencias para resolver todo, siempre que los nombres no se solapen. Una función es por supuesto un objeto, pero su resultado está unificado internamente, y sólo en global y público se puede mirar dentro. me gusta la lógica de python))))
hay cierres y es posible escribir sin oop en absoluto, al menos en el antiguo, lo que uno quiera
Bueno, se puede, pero aún así el bloque de construcción mínimo es un objeto
Hace tiempo que no lo veo...
¿Realmente se ha puesto otro nombre de usuario?
No, no es Peter, es un estilo de escritura diferente.
la OOP de la empresa es Java. En nuestro dominio, se representa Du* *opy (espolvoreado para no empantanarse). Si quieres belleza de los objetos - tratar sobriamente de entender y recordar su API, afortunadamente el tema es conocido :-)
Pero todo es una mierda...
Para aumentar tu habilidad de programación, quizá quieras aprender algo que te haga pensar. Por ejemplo está Rebol/Red ( https://www.red-lang.org/)- una cosa impresionante, no está jodidamente claro pero es genial.
o un clásico, Smalltalk(https://pharo.org/). Alguien lo está usando incluso en producción.
Y todo esto de "vamos a escribir A+B en diferentes estilos" es un juego de niños, sinceramente.
Y entonces todas las preguntas sobre quién es más guay, OOP o FP desaparecerán por sí solas.
Bueno, se puede, pero aún así el bloque mínimo de construcción es la instalación
el objeto era un avance.
Cuando la programación orientada a objetos es más conveniente, utilizo la programación orientada a objetos, cuando necesito ahorrar memoria y tiempo, y codificar para mí mismo, me quedo con el procedimiento. Acabo de encontrar un artículo, quería escuchar opiniones, dónde/qué es mejor). Resultado - He escuchado muchas cosas diferentes en mi dirección, no sobre la programación) Todo es como siempre.
Así que nadie le dirá nada nuevo. Utiliza lo que te resulte cómodo, eso es todo.
Para minimizar los errores, existe todo un campo llamado programación probatoria (verificación formal en particular).
Como medida parcial para mejorar la calidad del código, puede sugerir que se siga algún estilo de codificación común (por ejemplo, el estilo de código de Google), que se utilicen aserciones, restricciones (override, especificadores de acceso) que de hecho no afectan a la ejecución pero que causan errores de compilación si se utilizan de forma incorrecta, que se familiarice con los enfoques de diseño en general
El hecho es que, aparte de las áreas críticas de programación, generalmente es más importante sacar la versión de producción rápidamente que la calidad del código, lo cual es malo pero cierto