Reglas de estructura. Aprender a estructurar los programas, explorar las posibilidades, los errores, las soluciones, etc. - página 10
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
No soy ajeno a la programación estatal y la he utilizado durante varios años. Sin embargo, después de algún tiempo de utilizar este método, decidí abandonarlo y desarrollé un modelo más transparente, más sencillo y más adecuado para operar sobre su base.
Lea atentamente este artículo: La autoprogramación como nueva forma de crear sistemas de trading automatizados
A continuación, lea atentamente estos comentarios al respecto.
Entonces, contempla con mucha, mucha alma una placa antiestética del artículo, y piensa en lo que podría significar:
Si, después de leer todo esto, sigues diciendo: "¡Vaya! La programación estatal es genial". - bueno, cuenta con ello.
Yo añadiría que el principal problema de la programación del Estado son las situaciones que producen muchos modos inútiles (véase la columna N del Estado). En la programación estatal, cada modo debe describir sus propias reglas por separado. Vamos a explicarlo con un ejemplo, digamos que estamos en el modo de compra. Todo va bien hasta que el robot decide abrir una posición más. ¿Y por qué no? Las condiciones para salir de la antigua posición no se han cumplido y es demasiado pronto para cerrarla, mientras que una nueva señal no debería perderse. Y aquí es donde empiezan los problemas, porque en el momento de la llegada de una nueva señal el robot está en modo Compra, mientras que las reglas para abrir una nueva posición están en modo Estado (esperando y buscando nuevas señales de entrada). Ahora en el modo de compra tenemos que volver a describir las mismas reglas de apertura de posiciones que se utilizan en el modo de estado. ¿Y si una nueva posición es de sentido contrario (cobertura)? Este puesto está abierto, pero ¿qué hacer con él? Al fin y al cabo, su lógica de gestión se describe en el modo de venta, mientras que el robot está en el modo de compra. Podemos simplemente cambiar al modo de venta, pero ¿qué hacer con la posición de compra restante? En general, en este caso tenemos que escribir un modo más inútil como BuyAndSell. La redundancia de modos produce una situación más: una misma acción es realizada por diferentes secciones de código. En definitiva, para los que les guste el lío de la programación exponencial, esto es lo mejor.
"Así es Mihalych" (c)... Eso es lo que estoy insinuando también.
(fcplm)
De ninguna manera.
Estaba pensando que si MQL5 soportara la herencia múltiple y una clase pudiera declarar métodos abstractos, se abriría una vía para usar interfaces, lo que sería genial para proyectos grandes.
Los métodos abstractos no están explícitamente prohibidos (a menudo utilizo una notación alternativa),
Y la herencia múltiple sería una gran ventaja.
Los métodos abstractos no están explícitamente prohibidos.
Citando a Rosh: ¿en qué te ayuda serrar leña?
El FAQ de Von está sentado en un cuadrúpedo y no se preocupa por los métodos abstractos y la herencia múltiple.
No importa si habrá métodos abstractos o no, de todos modos, la tarea de estructuración del proyecto no estará resuelta.
Por cierto, cuantas más variantes de implementación tenga uno y más difícil sea elegir qué variante utilizar.
Así, resulta que el programador se atasca a menudo en la tarea de la belleza del código. Es un arte por el arte.
Me he dado cuenta, en general (hablando por mí), de que cuantos más sellos de planificación de proyectos, más fácil es.
Entonces puede cambiar, modificar, volver a modificar, sobremodificar,
Pero el marco inicial (aunque no sea genial) marca el tono de toda la construcción.
Citando a Rosh: ¿Cómo te ayuda esto a serrar leña?
Luego puedes cambiar, volver a modificar, volver a modificar, volver a modificar,
pero el marco inicial (aunque no sea genial) marca el tono de toda la construcción.
La velocidad de aserrado de la leña aumentará.
Si usted ya tiene una idea clara de cómo y qué debe parecer - probablemente puede hacer todo inteligentemente en MQL4.
Y si no existe tal noción, significa que habrá muchos cambios y adiciones. Y la herencia múltiple permite realizar cambios con un coste mínimo.
Estoy de acuerdo con los métodos abstractos: es una forma bonita de grabar.
La velocidad de aserrado de la leña aumentará.
Si usted ya tiene una idea clara de cómo y qué debe parecer - probablemente puede hacer todo inteligentemente en MQL4.
Y si no se tiene esa idea, significa que hay que hacer muchos cambios y adiciones. Y la herencia múltiple, en particular, permite realizar cambios con un coste mínimo.
Hoy en día se intenta abandonar la herencia en favor de la inclusión. ¿Te imaginas la actitud ante la herencia múltiple?
FAQ:
De ninguna manera.
No lo es. Usando un interruptor... y utilizar un patrón de máquina de estado son dos cosas diferentes. En el texto se puede ver que no existe ningún patrón, al igual que en el artículo que has citado.
Dice algo así como "He inventado un sistema ganador único..." y a continuación una declaración de martinismo.