Reglas de estructura. Aprender a estructurar los programas, explorar las posibilidades, los errores, las soluciones, etc. - página 5

 
  1. Todos mis proyectos comienzan con una interfaz. Una interfaz bien diseñada => estructura óptima del proyecto.
  2. Desarrollo la estructura de los datos (variables) - el rendimiento depende de ello.
  3. Me aseguro de que cada bloque funciona correctamente y sólo entonces lo optimizo.
  4. Cuando el proyecto esté listo, hay que someterlo a pruebas. Corregir los errores y "no convenientes" encontrados.
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных
Документация по MQL5: Стандартные константы, перечисления и структуры / Структуры данных
  • www.mql5.com
Стандартные константы, перечисления и структуры / Структуры данных - Документация по MQL5
 
FAQ:
Leo los TdR, y si no se me ocurre una solución en forma de estructura, me dedico a otros proyectos, normalmente nunca empiezo la implementación el primer día. Si el programa no es un ICL o XML, entonces leo, calculo las variaciones de implementación, los tipos de estructura, las clases. Cuando tengo una imagen general en mente, empiezo a cortar bloques o a escribir módulos básicos. Si algo no funciona, me dejo caer en el sofá con algún juguete tipo tetris y juego hasta que resuelvo completamente el problema, o hasta que me aburro :)
Eso me llamó la atención: "......... si la solución en forma de estructura no viene a la mente por sí misma.........". Aquí también asocio la formación de una estructura de proyecto armoniosa en mi cabeza con la oportunidad de empezar a trabajar en el proyecto. Hasta que se forme, pospongo la escritura de cualquier cosa. Suele ser demasiado costoso hacer cambios estructurales en lo que ya está escrito. Es mejor dedicar tiempo a pensar en lo básico al principio.
 

Por cierto acerca de los juguetes - justo hoy en algún lugar de las noticias han leído que Tetris y similares, mejorar la capacidad cognitiva - por lo que confirmo, pasando por las opciones en el campo de juego cerebros paralelno como si en el trabajo subconsciente en otras tareas.

SZS, como la optimización de las neuronas :)

DC2008:
  1. Todos mis proyectos comienzan con la interfaz. Interfaz bien pensada => estructura óptima del proyecto.
  2. Desarrollo la estructura de datos (variables) - el rendimiento depende de ello.
  3. Me aseguro de que cada bloque funciona correctamente y sólo entonces lo optimizo.
  4. Cuando el proyecto esté listo, hay que someterlo a pruebas. Corregir errores y "no conveniente" encontrado.

1. si hay una necesidad en la transmisión de datos, pienso primero en ella, en la estructura de datos, en el protocolo, en el formato. si no, pienso en el mismo orden. si hablo de µl, casi todos los bloques están escritos y optimizados desde hace tiempo, muy raramente tengo que escribir algo por separado, suelo hacerlo con complementos sobre la funcionalidad existente.

ZZZY. En principio, la mayor parte del tiempo se dedica al desarrollo de algoritmos.

 
FAQ:

Por cierto acerca de los juguetes - justo hoy en algún lugar de las noticias han leído que Tetris y similares, mejorar la capacidad cognitiva - por lo que confirmo, pasando por las opciones en el campo de juego cerebros paralelno como si en el trabajo subconsciente en otras tareas.

SZS, como la optimización de neuronki :)

Siempre tengo a Sapper en esta función).


 
FAQ:

Por cierto sobre los juguetes - justo hoy he leído en algún lugar en las noticias que Tetris y similares, mejorar las capacidades cognitivas - por lo que confirmo, repasando las opciones en el campo de juego cerebros trabajan en paralelo como en el subconsciente también en otras tareas.

...

¿Este efecto sólo funciona en horizontal o en otras posiciones queda? :)

Mis abstracciones funcionan mejor en horizontal, aunque es importante no caer en un sueño flojo y dulce :)

 

Para intercambiar ideas / aprender unos de otros, propongo tomar un problema más o menos práctico y reestructurarlo juntos.

Por ejemplo, al menos esbozar la estructura básica (o más exactamente, las variantes de dichas estructuras) para dicho problema:

Hay un Asesor Experto escrito así (por ejemplo, para probar una idea de trading). Supongamos que la idea en el Probador de Estrategias (en el cliente) muestra resultados prometedores. Ahora tenemos que reescribir el Asesor Experto para que sea más fácil de desarrollar. Y en particular, para dotarlo de un panel de control gráfico para el usuario.

Es deseable, o bien hacer el panel conmutable (para la optimización en el probador), o bien trasladar toda la realización "no gráfica" del EA a un archivo conectable (.mqh), que puede entonces conectarse a la interfaz gráfica sin cambios (para excluir) las diferencias en el funcionamiento de las versiones "probadora" y "gráfica".

Me gustaría escuchar-leer las consideraciones sobre la estructuración de un proyecto de este tipo. En particular, sobre la implementación del modelo de control dirigido por eventos en un proyecto de este tipo. Supongamos que la implementación dual (probador + panel) es un requisito estricto del cliente (es decir, el proyecto debe realizarse de cualquier manera, sólo se puede elegir el método de implementación).

¿Echamos un vistazo a la tarea?

 

pero para MT4 :)

ZS. En general, es demasiado pequeño, tengamos un problema más global.

 
FAQ:
pero para MT4 :)
Bueno, va a ser difícil con el panel de control allí, y es difícil de manejar las clases... )))
 
MetaDriver:
Bueno, sería difícil lidiar con un panel de control allí. Y las clases no son tan fáciles de manejar... )))

Yo, en cambio, tengo todo para ello :)))

ZS. Es que paso de los cinco. Así que sin mí. Mejor una simple tarea algorítmica abstracta.

 
FAQ:
Pero tengo todo para eso :)))

Así que dime (en general) cómo se tapan estos agujeros en el 4. ¿Está todo en DLL's? :)