Reglas de estructura. Aprender a estructurar los programas, explorar las posibilidades, los errores, las soluciones, etc. - página 18
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
Oh, Vladimir, no es tan fácil con tu circuito. ¿Dices que sólo hay que reescribir el controlador? Bueno, he contado muchas más partes dependientes de la plataforma:
¿Cómo se obtiene el historial de mercado y el historial de operaciones? ¿Y la información sobre la posición actual no se tomará del terminal, por casualidad? Y si hay que implementar el módulo de volatilidad, ¿una API más que depende de la plataforma?
¿Escribirá adaptadores? ¿Cuántos habrá? Para el historial de mercado - un adaptador, para el historial de operaciones - otro, para trabajar con las posiciones - un tercero. Así que, al final, habrá el doble de módulos, y la misma cantidad de código dependiente de la plataforma.
No es así como veo el problema.
Sólo todo lo que es rojo es bastante estable, todo lo que viene de la plataforma no cambia con los años, si usted necesita para otra plataforma, también hay una API bien establecida, reescribir ningún problema.
Pero todos los módulos con flechas verdes son propios, y casi siempre son reelaboraciones activas (no hay límite para lo ideal).
El pronóstico direccional fue escrito, luego vino la nueva idea de profundizar y expandir, bueno, como ahora es comprar, pero tenemos que prepararnos para vender, lentamente reducir el volumen.
Así que empecé a utilizar dos módulos.
MM Corrector también es un esquema dinámico, ahora funciona con posiciones, luego de repente tuvo una idea y decidió cambiarlo por posiciones largas (entrada suave al mercado).
El Market Driver debería ser estable porque tiene salida a la API dependiente de la plataforma, por lo que la formalización es clara, pero será un lío porque la API ofrece muchas posibilidades.
No es así como veo el problema.
Justo todo lo que es rojo es bastante estable, todo lo que viene de la plataforma no ha cambiado desde hace años, si lo necesitas para otra plataforma también hay una API bien establecida, reescribir no es un problema.
Una de las ideas importantes del esquema no es el número de piezas dependientes de la plataforma, sino su estricta localización. Es decir: el propio TS (predictores + módulos MM) - es un diseño independiente de la plataforma, pero las fuentes de datos son los indicadores y el conductor del mercado, respectivamente dependientes (el historial de comercio, alimentado a la entrada del corrector de recomendaciones - es también esencialmente el indicador).
La consecuencia: una zona de intervención claramente delimitada y no superpuesta a
1. La migración.
2. Mejora de la ST, en particular, del escalado.
Pero todos los módulos con flechas verdes son propios, y casi siempre un rediseño activo (no hay límite para lo ideal).
El pronosticador direccional fue escrito, luego vino la nueva idea de profundizar y expandir, bueno, como ahora es comprar, pero necesitamos prepararnos para vender, lentamente reducir el volumen.
Así que empecé a utilizar dos módulos.
El Corrector MM también es un esquema dinámico, ahora trabaja con la posición, luego de repente se espabiló y decidió cambiarlo por la equidad (entrada suave al mercado).
El Market Driver debería ser estable porque tiene salida a la API dependiente de la plataforma, de ahí que la formalización sea clara, pero habrá mucho lío porque la API proporciona muchas características.
Nadie prometió la ausencia de complicaciones :) Pero piensa que si todas esas llamadas directas a la API no se localizan en el controlador, sino que se mezclan con los códigos de los predictores y los módulos MM.............
;)
Nikolay, tu post es muy sensato, sin embargo me comprometo a defender el esquema propuesto (su universalidad).
Estoy de acuerdo, sólo quiero aclarar (en esta ocasión) a Vasily. Una de las ideas importantes del esquema no es el número de partes dependientes de la plataforma, sino su estricta localización. Es decir: el propio TS (predictores + módulos MM) - es un diseño independiente de la plataforma, pero las fuentes de datos son los indicadores y el conductor del mercado, respectivamente dependientes (el historial de comercio, alimentado a la entrada del corrector de recomendaciones - es también esencialmente el indicador).
La consecuencia: una zona de intervención claramente delimitada y no superpuesta a
1. Migraciones.
2. Mejora de la ST. En particular, el escalado.
Sin embargo, si en cualquier modificación nos ceñimos cuidadosamente a la división de las partes del sistema dependientes/independientes de la plataforma, entonces, por ejemplo, en nuestra situación actual podemos apoyar fácilmente el desarrollo de EAs para ambas plataformas (MT4/5), que sería una molestia en los sistemas de comercio dependientes de la plataforma.Puede haber cualquier número de módulos dentro de los componentes marcados en el esquema. Esto es normal. Creo que sólo es útil su clara disposición en tuberías. Las cuales no deben mezclarse dentro del código sin una necesidad absolutamente inevitable, es decir. Debe evitar barajar en lo posible. Esto le permite tener siempre bien definidos y convenientes los puntos de acoplamiento de los módulos al escalar hacia las multiherramientas. Mire el esquema desde este ángulo, lo encontrará usted mismo.
Ver arriba. // Pero la entrada del corrector MM es el punto más conveniente para integrar una nube de predictores de una sola moneda (un solo instrumento, más precisamente) en la cocina multidivisa (multiinstrumental).Nadie prometió la ausencia total de complejidades. :) Pero piensa que si todas estas llamadas directas a la API no se localizan en el controlador, sino que se mezclan con los códigos de los predictores y los módulos MM.............
;)
OK, usemos eso como base (pero añadamos un módulo de parada, parece razonable y nadie tiene ninguna objeción),
y pensar qué más falta en este esquema, o rehacerlo.
Vale, tomémoslo como base (sólo añadir un módulo para trabajar con topes, parece razonable y nadie tiene ninguna objeción),
y pensar en qué más falta en este circuito, o rehacerlo.
Voy a pensar en la reelaboración-mejora (dejar que se elabore).
La carencia es más obvia - este esquema obviamente carece de la GUI (subsistema de monitoreo/control visual). Quiero desarrollar un esquema unificado (¡y conveniente!) de interacción del Asesor Experto con la GUI. Hasta ahora, soy espontáneo en este asunto, lo que realmente me molesta. Me gustaría conseguir el mismo objetivo (abstracción total de datos en ambas direcciones). Por eso sugerí la tarea de la interfaz EA/GUI para la formación, me interesa mercantilmente, quería obtener algunas ideas del público.
Puede haber cualquier número de módulos dentro de los destacados en los componentes del esquema. Esto es normal. Sólo me parece útil tener su disposición clara de la tubería. Que no debe ser barajado dentro del código sin necesidad absolutamente inevitable. es decir. Esto permite tener siempre bien definidos y convenientes los puntos de acoplamiento al escalar hacia las multiherramientas. Mire el diagrama desde este ángulo y lo encontrará usted mismo.
La expansión ilimitada de los módulos conlleva graves problemas en el futuro. Tienes la lógica del Asesor Experto prácticamente dispersa en diferentes módulos. Los propios módulos interactuarán entre sí, y no hay garantía de que los enlaces entre ellos no se conviertan en una maraña. En mi opinión, todas las casillas marcadas en verde son elementos de un sistema de negociación. Descomponerlos en diferentes módulos viola uno de los principales principios de programación: la encapsulación de datos y métodos dentro de una tarea.
Ya que todo el mundo ha empezado a publicar sus propios esquemas, yo también lo haré. Esta vez se trata de un esquema aún más abstracto:
Las flechas negras describen relaciones rígidas. Los grises son interrelaciones privadas dentro del módulo, no son importantes. Además, la clase del robot de comercio puede dirigirse directamente a la API de la plataforma, pero la independencia de la plataforma se reduce.
La expansión ilimitada de los módulos conlleva graves problemas en el futuro. Tienes la lógica del Asesor Experto prácticamente dispersa en diferentes módulos. Los propios módulos interactuarán entre sí, y no hay garantía de que los vínculos entre ellos no se conviertan en una maraña. En mi opinión, todas las casillas marcadas en verde son elementos de un sistema de negociación. Descomponerlos en diferentes módulos viola uno de los principales principios de programación: la encapsulación de datos y métodos dentro de una tarea.
Ya que todo el mundo ha empezado a publicar sus propios esquemas, yo también lo haré. Esta vez se trata de un esquema aún más abstracto:
Las flechas negras describen relaciones rígidas. Los grises son interrelaciones privadas dentro del módulo, no son importantes. Además, la clase del robot de comercio tiene derecho a acceder directamente a la API de la plataforma, pero esto reduce la independencia de la plataforma.
En cuanto al rediseño-mejora, me lo pensaré (dejaré que se elabore).
La carencia es más obvia - este esquema obviamente carece de GUI (subsistema de monitoreo/control visual). Quiero desarrollar un esquema unificado (¡y conveniente!) de interacción entre el Asesor Experto y el GUI. Hasta ahora, soy espontáneo en este asunto, lo que realmente me molesta. Me gustaría conseguir el mismo objetivo (abstracción total de datos en ambas direcciones). Por eso sugerí la tarea de la interfaz EA/GUI para la formación, me interesa mercantilmente, quería obtener algunas ideas del público.
Pasa de la tarea. ¿Cuáles son las tareas más demandadas en la GUI?
Ve a partir de ahí. Describa lo que quiere obtener, seleccione los títulos comunes, haga un marco, luego añada algunas cosas más, vea lo fácil que es cambiar el marco.
Entonces entenderás cómo debe ser, vuelve a escribirlo todo. Yo lo veo así.
MetaDriver lo dice bien, y su sistema es correcto. Dick_fx también añadiría que el "controlador de operaciones" debería trabajar con 10-20 plataformas para utilizar los mejores precios.
Pero utilizar un sistema tan correcto sólo es conveniente en condiciones ideales: sin errores de estrategia, sin intervención del usuario, sin fuerza mayor... Y en la realidad esto no suele ser así.
Permítanme dar un ejemplo de dick_fx: 25 estrategias están trabajando, el agregador (conductor de comercio) los recoge en una posición neta y los pone en el mercado, todo está bien. De repente, algo va mal en la estrategia 17-th y da previsiones poco saludables - dice que hay que abrir al 50% del depósito. El Asesor Experto se abre obedientemente.
Qué hace un casillero trivial a la MT4:
Ahora pasemos a la "contabilidad correcta". ¿Qué debe hacer el operador para corregir el error (una operación con un margen del 50%, un error lógico evidente)?
La pregunta es: ¿qué es más fácil? Obviamente, la variante con MT4.
¿Y qué es más barato? Obviamente, la opción de la red.
¿Cuál es la conclusión? Hacer un controlador de mercado con una GUI de MT4 ;)
Y una cosa más.
Este es todo el razonamiento de los comerciantes "correctos", e incluso de los programadores. Si lo hacen por gusto, en la cuenta con un buen depósito, entonces es la única manera de hacerlo.
Si tocamos el tema de la escritura experta, resulta que nadie la necesita "bien". Las multitudes de comerciantes-clientes no pueden cambiarse, así que hay que escribir "para ellos".
Se acepta la opción de "dejar mi trabajo". =)
Y una cosa más.
Este es todo el razonamiento de los comerciantes "correctos", e incluso de los programadores. Si lo hacen por gusto, en la cuenta con un buen depósito, entonces es la única manera de hacerlo.
Si tocamos el tema de la escritura experta, resulta que nadie la necesita "bien". Las multitudes de comerciantes-clientes no pueden cambiarse, así que hay que escribir "para ellos".
Se acepta la opción de "dejar mi trabajo". =)