El EOP para escolares. - página 6
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
DE ACUERDO. Da tu definición de captador.
no es un caballo
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.
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.
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))
Todo está claro para ti. No se puede explicar).
Sigue congelando tus orejas para fastidiar a tu abuela.
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
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.
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 ...
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.
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
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.