El EOP para escolares. - página 6

 
Ihor Herasko:

DE ACUERDO. Da tu definición de captador.


no es un caballo

 
Dmitry Fedoseev:


no es un caballo.

Pensé que estaba tratando con alguien que podía explicar lo que sabe. Pero aquí, incluso a nivel de definiciones, hay problemas.

 
Ihor Herasko:

Pensé que estaba tratando con alguien que puede explicar lo que sabe. Pensé que estaba tratando con alguien que podía explicar lo que sabe.

Sí, fantasea como quieras, hace tiempo que entendí todo con algunos de vosotros aquí también, dispuestos a congelaros las orejas para fastidiar a vuestra abuela.

 
Dmitry Fedoseev:

Puedes fantasear todo lo que quieras, yo también he entendido todo con algunos de vosotros aquí durante mucho tiempo.

Todo está claro para ti. No se puede explicar))

 
Ihor Herasko:

Todo está claro para ti. No se puede explicar).

Sigue congelando tus orejas para fastidiar a tu abuela.

 
Alexey Viktorov:

Lo he leído desde el primer minuto de su creación.

la lectura no es suficiente, imho, usted necesita para tratar de establecer las tareas y escribir en el estilo de procedimiento, entonces (no es difícil) volver a escribir esta tarea en el estilo de OOP

Como ha escrito TC en repetidas ocasiones, la POO permite ampliar rápidamente la tarea, acelera el desarrollo y reduce el número de errores al escribir el programa

Para MQL: Uno de los problemas que menos me gustan es el cierre parcial de una serie de órdenes; en un estilo de programación procedimental, después de llamar a un subprograma que cerraría una orden, hay que organizar el tratamiento de los errores: ¿qué hacer si no consigo cerrar todas las órdenes parcialmente en una sola llamada? - ¿el servidor no permitió cerrar parcialmente? - Hice esta pregunta a principios de año, bueno, como de costumbre, en el 99% de los casos todas las soluciones comunes se redujeron al análisis de los comentarios de orden - como leer allí, el servidor escribirá todo allí.....imho, no profesional

En el estilo OOP este problema se resuelve "en 2 clics", llamamos al método que cierra parcialmente el pedido, y los datos sobre el estado del pedido - ticket, necesidad de su modificación..... y métodos que trabajan con el pedido se almacenan en la clase ORDER - solución con la máxima flexibilidad y escalabilidad para las próximas tareas, imho


lo mismo se aplica a las tareas con gráficos en MQL - si tienes una etiqueta de texto, no es un problema trabajar con ella, pero si tienes 10-100 etiquetas? - ¿Qué pasa si necesitas cambiar la combinación de colores, selectivamente para algunas etiquetas de color "coral", y para otras "perla con botones"? .... y después de una semana tardó en añadir 3 botones más.... y una semana más tarde se necesitaron otros 10 botones para eliminar....


ZS: otro tema de lucha contra los molinos de viento .... no, me acordé de alguien (olvidé su apellido)) ) - ¿quién dijo que la tierra es redonda y luego se quemó? )))) - así es la lucha contra el analfabetismo y/o la ampliación de la mente

 
Igor Makanu:

la lectura no es suficiente, imho, usted necesita para tratar de establecer las tareas y escribir en el estilo de procedimiento, entonces (no es difícil) volver a escribir esta tarea en el estilo de OOP

Como ha escrito TC en repetidas ocasiones, la POO permite ampliar rápidamente la tarea, acelera el desarrollo y reduce el número de errores al escribir el programa

Para MQL: Uno de mis problemas menos favoritos es el cierre parcial de una serie de órdenes; en un estilo de programación procedimental, después de llamar a un subprograma que cerraría una orden, es necesario organizar el manejo de errores - ¿qué hacer si no logré cerrar todas las órdenes parcialmente en una sola llamada? - ¿el servidor no permitió cerrar parcialmente? - Hice esta pregunta a principios de año, bueno, como de costumbre, en el 99% de los casos todas las soluciones comunes se redujeron al análisis de los comentarios de orden - como leer allí, el servidor va a escribir todo allí.....imho, no profesional

En el estilo OOP este problema se resuelve "en 2 clics", llamamos al método que cierra parcialmente el pedido, y los datos sobre el estado del pedido - ticket, necesidad de su modificación..... y métodos que trabajan con el pedido se almacenan en la clase ORDER - solución con la máxima flexibilidad y escalabilidad para las próximas tareas, imho


lo mismo se aplica a las tareas con gráficos en MQL - si tienes una etiqueta de texto, no es un problema trabajar con ella, pero si tienes 10-100 etiquetas? - ¿Y si necesita cambiar el esquema de colores, selectivamente para algunas etiquetas de color "coral", y para otras "perla con botones"? .... y después de una semana tardó en añadir 3 botones más.... y una semana después había que quitar otros 10 botones....


ZS: otro tema de lucha contra los molinos de viento .... no, me acordé de alguien (olvidé su apellido)) ) - ¿quién dijo que la tierra es redonda y luego se quemó? )))) - así es la lucha contra el analfabetismo y/o la ampliación de horizontes

En mi opinión, en mql el conjunto de problemas a resolver vía OOP es muy estrecho. El lenguaje en sí, me parece, no es más que OOP en C++ o lo que sea. Y esta POO se ofrece en forma de biblioteca estándar. Y a esta OOP se sugiere añadir, si no, no diría, otra OOP. Y luego otro paso... Bien dicho Warlock, aunque enfadado, pero benévolo, para mis tareas OOP es como un plato giratorio para perros. Y de qué sirve plantear un problema y luego implementarlo mediante POO si ese problema se puede resolver en estilo procedimental sin problemas.

Por ejemplo, tome .mqh de fxsaber`a para escribir códigos para MT5 así como para MT4. Tal vez alguien lo necesite, pero mira quién... Los que no quieren o no pueden dominar mql5. O tomar el iCanvas de Nikolay... olvido su apellido. Parece ser una biblioteca útil, pero no es fácil entenderla, y no hay documentación, ni siquiera una mínima descripción. No es una queja, lo siento Nikolay, es un hecho. Así que, cuando decidí intentar escribir una etiqueta gráfica, fue más fácil escribirla sin referencia a la biblioteca estándar ni a la biblioteca de Nikolai.

 
Alexey Viktorov:

En mi opinión, mql tiene un conjunto muy estrecho de tareas que necesitan ser resueltas a través de OOP. El lenguaje en sí me parece que no es más que un OOP en C++ o algo así. Y esta POO se ofrece en forma de biblioteca estándar. Y a esta OOP se sugiere añadir, si no, no diría, otra OOP. Y luego otro paso... Bien dicho Warlock, aunque enfadado, pero benévolo, para mis tareas OOP es como un plato giratorio para perros. Y de qué sirve plantear un problema y luego implementarlo mediante POO si ese problema se puede resolver en estilo procedimental sin problemas.

Desgraciadamente tienes un 90% de razón, pero sólo porque las estrategias de trading que piden los traders para escribir .... Francamente, son primitivos. Hubo cierto entusiasmo cuando fue posible crear paneles gráficos de calidad en MQL, pero resultó que los usuarios finales tampoco lo necesitaban - este es el problema de la industria, el público, aunque abigarrado, está interesado en ello .... sólo quieren un botón: dinero ...

Alexey Viktorov:

Por ejemplo, tome .mqh de fxsaber`a para escribir códigos para MT5 así como para MT4. Tal vez alguien lo necesite, pero mira quién ... El que no quiere o no puede dominar mql5.

Estoy usando esta librería, porque necesito mt5, pero no quiero gastar mi tiempo estudiando el sistema de órdenes, pero intenté preguntarlo una o dos veces en el hilo de novatos de MT5... Realmente no quiero gastar mi tiempo estudiando el sistema de órdenes, pero lo intenté un par de veces en la rama de novatos de MT5... Sin resultados - esencialmente nadie en el foro sabe cómo funciona el sistema de órdenes y da respuestas a mis preguntas... Bueno, es un "Jumblebug", por decirlo suavemente.

Alexey Viktorov:

O tomar el iCanvas de Nikolay... olvido su apellido, entiendes. Parece ser una biblioteca útil, pero no es fácil entenderla, y no hay documentación, ni siquiera una mínima descripción. No es una queja, lo siento Nikolay, es un hecho. Así que, cuando decidí intentar escribir una etiqueta gráfica, fue más fácil escribirla sin referencia a la biblioteca estándar ni a la biblioteca de Nikolai.

he usado la biblioteca de @Nikolai Semko un par de veces - nada ordinario, sólo conectarla y usarla... el principio es como el 99% de los EAs liberados diariamente en KB - el moderador no se molesta con el sistema de orden allí, ¿verdad? - el AdS está escrito en forma de OOP y produce cualquier EA que se le ocurra

 
Alexey Viktorov:

En mi opinión, mql tiene un conjunto muy estrecho de tareas que necesitan ser resueltas a través de OOP. El lenguaje en sí me parece que no es más que un OOP en C++ o algo así. Y esta POO se ofrece en forma de biblioteca estándar. Y a esta OOP se sugiere añadir, si no, no diría, otra OOP. Y luego otro paso... Bien dicho Warlock, aunque enfadado, pero benévolo, para mis tareas OOP es como un plato giratorio para perros. Y de qué sirve plantear un problema y luego implementarlo mediante POO si el problema se puede resolver en estilo procedimental sin problemas.

Por ejemplo, tome .mqh de fxsaber para escribir los códigos para MT5 como para MT4. Tal vez alguien lo necesite, pero mira quién. A alguien que no quiera o no pueda dominar mql5. O tomar el iCanvas de Nikolay... olvido su apellido. Parece ser una biblioteca útil, pero no es fácil entenderla, y no hay documentación, ni siquiera una mínima descripción. No es una queja, lo siento Nikolay, es un hecho. Así que, cuando decidí intentar escribir una etiqueta gráfica, fue más fácil escribirla sin referencia a la biblioteca estándar ni a la biblioteca de Nikolai.

Laaplicación de la POO implica un nivel de complejidad de las tareas, mucho mayor que en el algotrading. Por eso hay disputas. La POO es necesaria para los programadores y desarrolladores profesionales para tratar programas complejos. Hay poco espacio para un enfoque tan serio. Es un error explicar el significado de la POO con pequeños ejemplos. El sentido de la POO está en el trabajo a gran escala con gran cantidad de datos y funciones. La diversidad de datos requiere una separación y clasificación, y luego está la relevancia de la encapsulación de la descripción, la herencia de las propiedades y los métodos entre las clases separadas jerárquicamente.

Esto no tiene sentido en las tareas pequeñas.

 
Cuando los programadores aprenden POO, se introducen inmediatamente en el mundo de los grandes programas y comienzan a navegar por él. Sin embargo, su propia función en este "mundo" puede ser pequeña. No importa. Sólo se unen al mar común de programas y bibliotecas y lo que hacen allí. ¿Lo necesitan los algotraders? Es difícil de decir. Los que lo necesiten lo dominarán. El resto se lo pensará mucho e intentará algo y lo llamará OOP...