Reglas de estructura. Aprender a estructurar los programas, explorar las posibilidades, los errores, las soluciones, etc. - página 3
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
Vamos, que no tenía ningún modelo, luego empecé con el procedimiento, luego cambié al modelo de objetos.
Y en general, por defecto MQ nos da un modelo basado en eventos. Inicialmente se nos dan los acontecimientos por los que todo sucede.
¿Estamos hablando de mq5?
así que estamos hablando de lo mismo.
De la ramallamada "Errores, fallos, preguntas":
Un problema muy típico para el inicio del diseño: cómo organizar (estructurar) el manejo de eventos en un programa para que éste (el programa) pueda seguir desarrollándose y, al mismo tiempo, se pueda rehacer mínimamente lo que ya se ha hecho.
¿Quiere discutir las opciones?
En general, se trata de una cuestión más global y no se trata sólo de organizar un buen modelo de evento. Depende mucho de la propia lengua. Por desgracia, los medios lingüísticos de MQL5 están al nivel de los años 80 del siglo pasado. Los estándares de programación modernos se alejan de los principios de programación OOP originales. Hoy en día, la descomposición es preferible a la herencia, el polimorfismo está garantizado por los enlaces horizontales no jerárquicos a nivel de interfaz, y la reutilización del código está garantizada por las ricas colecciones de bibliotecas estándar, el diseño descomposicional y la inclusión transparente de construcciones de terceros en el proyecto.
¿Existe algún tipo de literatura, por ejemplo?
Concretamente sobre este tema:
¿Qué idioma considera un modelo a seguir (en términos de modernidad y usabilidad)?
Java/C#
Y ni siquiera se trata de mis prejuicios (aunque no me faltan), sino de que estos lenguajes son el producto final de una larga evolución en la tecnología de la programación. Se crearon en nuestra época y se basaron en la experiencia de sus predecesores.
Antes de redactar un proyecto de gran envergadura, es buena idea establecer una infraestructura clara para apoyar el proyecto:
¿Existe algún tipo de literatura, por ejemplo?
Por supuesto que sí.
// Sobre la literatura: compartamos las fuentes literarias. Pero no olvidemos que la comunicación en directo es a veces mucho (órdenes de magnitud) más eficaz para el aprendizaje que los libros (incluso los buenos).
--
El libro fue muy útil en su momento (principios de los 90):
B.Liskov, J.Gatag. "Uso de abstracciones y especificaciones en el desarrollo de software".
De él aprendí bien el punto principal de la programación orientada a objetos, que no es la posibilidad adicional de cortar el programa en cómodos "cubos" - esto es sólo una comodidad adicional que acompaña. El punto principal es la abstracción de datos.
usted piensa en forma orientada a objetos, yo pienso en forma funcional )
1. La abstracción procedimental (algorítmica) es una característica de la programación funcional. La entidad de abstracción es el procedimiento (función). Permite separar una solicitud para realizar una acción o un cálculo de su implementación. El código de la función se aísla en un bloque separado (procedimiento, función), este código es referido a través de la disociación de los parámetros formales/reales (esta es la esencia y característica principal del enfoque procedimental). El programa es capaz de permanecer sin cambios cuando es necesario cambiar la forma (algoritmo) de cálculo o acción (por ejemplo, escribir en un archivo).
Pero si un programa necesita cambiar alguna estructura de datos básica (matrices globales, por ejemplo), va a tener que reescribir muchos procedimientos que trabajan con estos datos. -- Esta es una limitación básica del estilo de programación procedimental.
2) Abstracción de datos - encapsulación de las estructuras de datos básicas (junto con las operaciones básicas sobre las mismas) en entidades separadas ("clases"), cumpliendo la regla básica: no referirse nunca a ellas (a los datos encapsulados) directamente, sino única y exclusivamente a través de las funciones de la misma clase, creadas específicamente para ellas ("interfaz"). De este modo, se consigue la abstracción de la forma de almacenamiento de los datos de las formas de manipulación de los mismos.Y hay una oportunidad sin precedentes (en la programación procedimental) - desarrollar un programa sin preocuparse de antemano por las formas de representación de los datos. Dado que se accede a los datos a través de una interfaz estándar que no cambia, se pueden mejorar las formas de representación de los datos en cualquier etapa del desarrollo del proyecto, y este cambio no implica la necesidad de cambiar otras partes del proyecto. En la programación procedimental esto era imposible - la estructura básica de los datos determinaba estrictamente las formas de su procesamiento.
También me enseñaron a dibujar en papel, un lenguaje simplificado de algo, antes de escribir el programa, pero nunca me acostumbré.
Hoy en día, ningún programador normal dibuja diagramas de flujo. Todo son tonterías teóricas pensadas para enseñar a los escolares, pero no para trabajar en proyectos reales.
Dibujo en papel, me resulta más cómodo, a veces necesito hasta 50 hojas hasta que surge una estructura clara. Puedes, por supuesto, utilizar editores especiales, pero cada uno de ellos para mí es incómodo (limitado), imposible de realizar un vuelo de fantasía, en definitiva ralentizan el trabajo.
Y qué ocurrirá con tu estructura clara si a mitad, o incluso cerca del final del proyecto, el cliente cambia de repente:
Esta es una buena prueba para ver cómo de preparado y resistente está su proyecto al cambio. En la práctica, siempre hay que hacer frente a cambios en los requisitos iniciales. Por lo tanto, es mejor dejar de lado el paradigma "Proveer para todo" y pasar al paradigma "Tarea - Solución".