Discusión sobre el artículo "Desarrollo de un Asesor Experto multidivisas (Parte 4): Órdenes pendientes virtuales y guardado del estado"
No utilizaría una arquitectura así.
Imagina que MQ hiciera comercio virtual integrado en el lenguaje. Entonces no tendrías la idea de incrustar otras entidades en él, porque simplemente no se puede hacer a través de la herencia OOP - las fuentes no están disponibles. Se crearía una arquitectura diferente.
Objetos gráficos en una virtualización - bueno, eso es todo en la misma pila de nuevo.
La arquitectura se ha vuelto tan difícil de manejar que te hace sentir incómodo. En lugar de ensamblar a partir de ladrillos simples, has decidido crear ladrillos universales.
Volvemos a que no nos gusta mucho la implementación, pero nos gustan aún menos otras (que no están hechas pero se han pensado). Quizás en el proceso de desarrollo posterior sea posible hacerlo de otra manera, pero por ahora.
Sobre la situación con las fuentes inaccesibles: en esta implementación decidí simplemente aprovechar el hecho de que las fuentes están disponibles y se les puede añadir algo que no era necesario añadir de una vez. Intenté que esas adiciones fueran mínimas. La alternativa era crear varias clases herederas nuevas para la familia de clases CVirtual*. Este enfoque me parecía aún más engorroso. Pero es muy posible que lleguemos a ello cuando haya más clases y resulte feo almacenarlas en una carpeta.
Necesitaba objetos gráficos para controlar el desarrollo de las estrategias de negociación, así que se implementaron. Y la clase CVirtualOrder no se modificó en absoluto. Pero tuve que añadir cuatro nuevas líneas de código a la clase CVirtualReceiver. Elegí esta opción entre varias posibles.
Si no hay necesidad en la visualización gráfica de las posiciones virtuales, puede no usarlo o volver a la variante de la biblioteca del artículo anterior.
Volvemos a que no nos gusta mucho la implementación, pero nos gustan aún menos otras (que no están hechas pero se han pensado). Tal vez en un desarrollo posterior sea posible hacer las cosas de otra manera, pero por ahora es así.
Por desgracia, no tengo tiempo suficiente para mostrar mi visión sobre el ejemplo de refactorización parcial.
Después del primer lanzamiento, el Asesor Experto abre posiciones virtuales y reales, calcula, tal vez, algunos indicadores sobre los datos de precios. Es esta información la que compone el estado del EA en su conjunto. Si ahora recarga el terminal, el EA no sólo debe reconocer las posiciones abiertas como propias, sino también restaurar todas sus posiciones virtuales y los valores de cálculo necesarios. Si la información sobre las posiciones abiertas se puede obtener del terminal, la información sobre las posiciones virtuales y los valores de cálculo debe ser guardada por el propio Asesor Experto.
Imagine que el Asesor Experto trabaja en dos cuentas de trading de un mismo broker. Uno de los terminales está apagado. Durante este tiempo, las posiciones virtuales han cambiado en el que está funcionando. ¿Cómo hacer coincidir el comportamiento del Asesor Experto con el terminal que no ha dejado de funcionar?
Como lo hago. No guardo para nada las posiciones virtuales. Al arrancar el Asesor Experto, todas las TS internas se lanzan en el probador virtual antes del TimeCurrent actual. Así, conseguimos que en el EA recargado todos los datos del momento actual coincidan con la versión sin recargar.
Por "recarga" entendemos también la situación en la que se produce una pausa en el trabajo del Asesor Experto. Por ejemplo, un OrderSend largo o una recarga. Por eso es necesario solicitar los datos de precios desde el momento de la última solicitud. Y ejecutarlos en una máquina virtual.
Lamentablemente voy justo de tiempo para mostrar mi visión con un ejemplo de refactorización parcial.
Usted ya presta mucha atención a la revisión del código de otras personas, por lo que le estoy muy agradecido.
Imagina que un Asesor Experto trabaja en dos cuentas de trading del mismo broker. Uno de los terminales está caído. Durante este tiempo, las posiciones virtuales han cambiado en la que está funcionando. ¿Cómo podemos hacer que el comportamiento del Asesor Experto coincida con el terminal que no ha dejado de funcionar?
Me he encontrado con una situación así, pero era un factor insignificante que afectaba al resultado de la negociación. Además, había veces en que el terminal que "dormía" el cierre de posiciones las cerraba a un precio más favorable. Por lo tanto, garantizar la plena identidad no era un fin en sí mismo.
Y si hay diferentes brokers, incluso los Asesores Expertos trabajando de forma sincronizada pueden mostrar resultados ligeramente diferentes debido a pequeñas diferencias en las cotizaciones. Aunque uno debe esforzarse por conseguir la identidad.
Cómo lo hago yo No guardo cuentas virtuales en absoluto. Al lanzar un Asesor Experto, todos los TS internos se lanzan en el probador virtual antes del TimeCurrent actual. Así conseguimos que en el Expert Advisor recargado todos los datos del momento actual coincidan con la versión sin recargar.
Es un planteamiento interesante, no me había planteado antes esta opción. Si lo entiendo bien, a la hora de utilizarlo, debemos tener una fecha fija de inicio de la operativa virtual, y debe ser la misma para distintas instancias de Asesores Expertos en distintos terminales. Esto no es difícil. Y hay que implementar un probador virtual o utilizar el que ya tienes preparado. Esto es más complicado.
- 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
Artículo publicado Desarrollo de un Asesor Experto multidivisas (Parte 4): Órdenes pendientes virtuales y guardado del estado:
Tras empezar a desarrollar un EA multidivisa, ya hemos obtenido algunos resultados y hemos conseguido realizar varias iteraciones de mejora del código. Sin embargo, nuestro EA fue incapaz de trabajar con órdenes pendientes y reanudar la operación después del reinicio del terminal. Añadamos estas características.
En el artículo anterior, hemos revisado significativamente la arquitectura del código para construir un EA multidivisa con varias estrategias de trabajo en paralelo. Tratando de lograr simplicidad y claridad, hasta ahora sólo hemos considerado un cierto conjunto mínimo de funcionalidades. Incluso teniendo en cuenta las limitaciones de nuestra tarea, hemos alterado significativamente el código de los anteriores artículos.
Ahora esperamos tener la base suficiente para aumentar la funcionalidad sin cambios radicales en el código ya escrito. Intentaremos hacer un número mínimo de ediciones sólo cuando sea realmente necesario.
Como desarrollo posterior, intentaremos hacer lo siguiente:
Empecemos por lo más sencillo: la gestión de las órdenes pendientes virtuales.
Autor: Yuriy Bykov