Mi enfoque. El núcleo es el motor. - página 16
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
Por el momento, tengo un cliente. Completo sus tareas muy rápidamente. 3-4 horas y una nueva ventana totalmente funcional está lista. Junto con la interfaz de conexión. También corrijo rápidamente los errores del motor y le envío nuevas versiones. 9 ventanas en pocos días + cambios en el motor, corrección de errores, adición de funciones... Todo muy rápido.
Debes tener mucho tiempo libre.
Entiendes que tú solo no eres suficiente. La masividad de su motor dependerá de que guste a otros programadores (usted solo no es suficiente para todos los clientes). Y si a los progermas no les gusta, entonces... por desgracia, el destino de tu creación será glorioso.
Los programadores no tendrán que entrar en el código del motor. Obtendrán la interfaz de conexión a la misma en el archivo. Ya lo he probado. Todo funciona.
Por el momento, tengo un cliente. Completo sus tareas muy rápidamente. 3-4 horas y una nueva ventana totalmente funcional está lista. Junto con la interfaz de conexión. También corrijo rápidamente los errores del motor y le envío nuevas versiones. 9 ventanas en pocos días + cambios en el motor, corrección de errores, adición de funciones... Todo muy rápido.
¿Lo dice bien? ¿3 o 4 horas para crear una ventana? ¿No hay minutos?
De hecho, lo hago desde hace más de un año. Y no me confundo)).
Para comparar, implemente lo mismo usando OOP. Tal vez te guste. :)
¿Lo dice bien? ¿3 o 4 horas para crear una ventana? ¿No hay minutos?
No. Puedes hacerlo en minutos si copias el código de otra ventana y haces los cambios. Pero me refería a crearlo desde cero, pensando en los gráficos y trabajando en el estilo.
Por cierto, Peter, no te olvides de añadir todo tipo de gráficos, como indicadores, solo en windows, con soporte para un par de formatos de datos(OHLC, como Zigzag, etc.). Espero que todo sea fácilmente implementable en tu proyecto.
Lo intentaré.
Lo intentaré.
No lo intentaré, lo haré). Aumenta la utilidad de tu creación.
¿Lo dice bien? ¿3 o 4 horas para crear una ventana? ¿No son minutos?
Qué tontería... hacer 3 ventanas en MQL incluso usando las librerías del kit de herramientas estándar de MT lleva 10 minutos y otros 20-30 minutos para ajustar la altura y XY de los botones, ediciones, etiquetas...
Veo dos posibilidades por las que el trabajo de Petr puede ser útil:
- creación de una aplicación separada para generar el código fuente MQL, es decir, constructor GUI y no entrar en detalles de cómo funciona, por lo que decir Visual MQL ++ )))
- O bien: hay personas que crean sus propias dificultades y las superan con éxito © Wingston Churchill
Me parece que todos los componentes OOP de Peter se aferran constantemente a los detalles.
Y el núcleo de la cuestión es precisamente la filosofía y la arquitectura del sistema.
Ya se ha dicho, con razón, cuáles son las cuestiones controvertidas, que parecen ser ventajas para Pedro y desventajas para sus oponentes:
- montón de variables globalmente accesibles, sin encapsulación alguna.
- falta de control de tipo
- una dependencia rígida de una implementación particular de almacenamiento de datos.
Y Peter dijo correctamente que el concepto de OOP (al menos en mis sugerencias) está diseñado para simplificar, "basado en la conveniencia del programador". La encapsulación, el control de tipos, las interfaces - todo esto está diseñado para eliminar la posibilidad de error, confusión, mal uso tanto como sea posible. Así es.
El concepto de Peter es el contrario. Todos los datos son accesibles desde cualquier lugar, el usuario desde cualquier parte del código tiene control total sobre todos los objetos del programa y puede percibirlos como quiera sin ninguna restricción de tipo (bueno, excepto las restricciones de MQL).
Peter dice que este concepto "permite alcanzar el máximo desarrollo. La usabilidad es lo segundo".
Personalmente, como programador, ya me disgusta que la comodidad pase a un segundo plano. Pero puedes sacrificar esto si consigues mucho más desarrollo. Bueno, quiero ver qué es. Donde el enfoque OOP con restricciones y encapsulación no permite alcanzar tal desarrollo, ya que este enfoque con acceso completo a la enorme gama de propiedades, arrojadas en un array de tamaños monstruosos. (Por no hablar de la necesidad de recordarlo todo).
Como bien se ha señalado anteriormente, el enfoque recuerda a la TurboVision de Pascal. Aunque, el control de tipos y las restricciones de encapsulación ya se han implementado en esa biblioteca.