Discusión sobre el artículo "Construimos un asesor usando módulos individuales"
Modularidad, intercambiabilidad, principios básicos de diseño. Creo que para la mayoría de los que desarrollan de forma más o menos habitual es obvio y el artículo no aporta nada nuevo. Pero para los recién llegados que se están familiarizando con la programación a través de MQL, puede abrirles los ojos).
dmc9966 :
Sr. Novichkov,
Gracias, Dan. Estoy encantado de ayudarle )
Sr. Novichkov,
Gracias por compartir su duro trabajo con la comunidad. Me estoy enseñando MQL y eventualmente quiero codificar mi propio EA, su trabajo con los módulos y el diseño de patrones me ayuda enormemente.
Muchas Gracias
Dan
Me gustó mucho este enfoque y, finalmente, un poco de estructura para una EA.
¿Qué hay que cambiar para adaptarlo a MQL4? Estoy utilizando la biblioteca MQL_Easy para desarrollar código común para mi EA en ambas plataformas.
Apreciaré su consejo. Gracias.
Manuraj Dhanda:
Me gustó mucho este enfoque y por fin algo de estructura para un EA.
¿Qué hay que cambiar para adaptarlo a MQL4? Estoy usando MQL_Easy biblioteca para desarrollar código común para mi EA en ambas plataformas.
Apreciaré su consejo. Gracias.
Para trabajar con MQL4 sólo tienes que intentar compilar el proyecto en MT4 )))) No debería haber muchos errores. El código es bastante simple
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
Artículo publicado Construimos un asesor usando módulos individuales:
Durante el desarrollo de indicadores, asesores y scripts, el desarrollor se ve obligado a crear constantemente fragmentos de código terminados, que no tienen relación directa con la estrategia de trading. En el artículo vamos a analizar diferentes métodos para proyectar asesores usando los bloques individuales proyectados anteriormente: trailing, filtros, horarios, etcétera. Asimismo, hemos analizado las peculiaridades de este tipo de proyectos.
Comenzaremos por intentar comprender qué aspecto puede tener un asesor así, proyectado "sobre la marcha" y de qué partes / componentes / módulos puede constar. ¿De dónde pueden proceder estos componentes? La respuesta es clara y comprensible: durante el desarrollo constante del trabajo, el desarrollador se ve obligado una y otra vez a proyectar componentes aparte con funcionalidad semejante e incluso coincidente.
Salta rápidamente a la vista que preparar cada vez un nuevo trailing (por ejemplo) supone un gasto inútil de tiempo. En general, el traling de cualquier asesor tendrá siempre las mismas tareas y aproximadamente los mismos parámetros de entrada. Por eso, el desarrollador debe proyectar el trailing una sola vez, y luego colocarlo en todos los asesores que tienen esta necesidad, invirtiendo en ello el mínimo esfuerzo. Lomismo podemos decir de multitud de otros componentes: el ya mencionado componente de horario, diferentes filtros y de noticias, módulos que combinan diversas funciones comerciales y otros.
Como resultado, obtendremos un asesor bastante caótico, preparado a partir de una especie de puzle conformado por diferntes módulos / bloques programáticos. Los módulos intercambian información entre sí y con la "parte central" del asesor, la "estrategia" que toma las decisiones. Vamos a representar una posible variante de interacción de varios módulos:
Autor: Andrei Novichkov