¿Alguien ha creado un sistema de comercio automatizado exitoso? ¿Cuál es su consejo? - 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
¡Genial! ¿Qué pasa con el beneficio con OOP. ¿Se irá enseguida después de aprenderlo?
La programación orientada a objetos le permite escribir un código compacto, claro y elegante. Se pasa varias veces menos tiempo escribiendo, modificando y depurando código, lo cual es muy caro. Puedes construir un sistema de trading mucho más sofisticado y probar muchas más opciones de trading. Por supuesto, si no tienes ninguna idea para un bot rentable - entonces es mejor no hacer nada en absoluto. Además, no hay que olvidar la probabilidad de pérdida directa en caso de errores, cuya probabilidad en un buen código OOP es mucho menor.
La programación orientada a objetos le permite escribir un código compacto, claro y elegante.
No es así.
Este no es el caso.
Bueno, si se establece una tarea para complicarla deliberadamente, entonces sí, hay más oportunidades para complicarla deliberadamente con la POO.
Pero si no te vuelves como Mono con Gafas, consigues un código mucho más claro, estructurado y mantenible con la POO.
No estoy en contra de la OOP, amigos. Me gusta la idea de su objeto. Y lo utilizo parcialmente, pero en forma de estructuras, o más bien de un conjunto de estructuras. En el trading es suficiente con almacenar todos los datos de un gráfico y no ejecutar bucles en cada barra. Pero creo que esto es todo lo que necesitamos. Por supuesto, se puede escribir todo en OOP, los que están acostumbrados a ello. Pero están tan lejos de ser rentables como las procesales. Toda la cuestión está en el sistema rentable, si lo tienes, puedes escribirlo por goto-code :)
El tema de la rama se cierne sobre la forma de solucionarlo.
Y lo utilizo en parte, aunque en forma de estructuras, o mejor dicho, de un conjunto de estructuras.
En Java tiene incluso su propio nombre: POJO (Plain Old Java Object)
;)
El código OOP es notablemente más claro, más estructurado y más fácil de mantener.
Esto no siempre es así y no depende de la POO, sino de la limpieza del código, de la nomenclatura.
No estoy en contra de la OOP, amigos. Me gusta la idea de su objeto. Y lo utilizo parcialmente, pero en forma de estructuras, o más bien de un conjunto de estructuras. En el trading es suficiente con almacenar todos los datos de un gráfico y no ejecutar bucles en cada barra. Pero creo que esto es todo lo que necesitamos. Por supuesto, se puede escribir todo en OOP, los que están acostumbrados a ello. Pero están tan lejos de ser rentables como las procesales. Toda la cuestión está en el sistema rentable, si lo tienes, puedes escribirlo por goto-code :)
El tema de la rama se cierne sobre la forma de solucionarlo.
El uso de estructuras no es OOP. Todos los beneficios de la POO comienzan cuando se empiezan a utilizar patrones de POO. Herencia, singletons, facetas de objetos, clases de interfaz, etc. Además, no puedes prescindir de la OOP si tienes más de 2 personas en tu equipo. Por ejemplo:
A continuación, usted mismo o encargue a 3 personas que escriban señales, por ejemplo, para 3 indicadores diferentes:
El lugar donde se utiliza la señal es suficiente para hacerlo:
Usted, como senor, está completamente abstraído de las implementaciones del cuerpo de la función. La aplicación y el indicador que se utilice no son importantes para usted. Sólo tienes que usar check_signal y ya está. En este ejemplo, se utiliza una función. Y si hay muchas funciones en una clase - usted tiene que insertar el interruptor donde la implementación depende de la configuración u otra elección. Además, si utilizas una base de datos o, por ejemplo, un archivo de registro en varios lugares, tienes que crear una variable global y controlar su estado en todas las etapas (si el archivo o la base de datos están abiertos, etc.). En el caso de que utilices un singleton para este propósito - puedes estar seguro de que dondequiera que utilices el archivo de registro/objeto base - siempre habrá una copia del objeto donde puedes reabrir la base/archivo, utilizar banderas de estado, hacer un registro con buffer para no escribir en el disco en cada salida, etc. Si tiene más de 10.000 líneas de código, la funcionalidad es un infierno para el desarrollador. Y dentro de medio año, cuando hayas olvidado la mitad de tu código, será un infierno rehacerlo. Además, un buen diseño OOP te permite añadir nuevas funcionalidades o editar las antiguas sin miedo a que todo se vaya al carajo si cambias algo en alguna parte.
¿Cuál es la diferencia en la OOP en la 5 y la 4? La iluminación. La diferencia en la configuración del entorno de las acciones es evidente. Bueno las barras están numeradas desde el final. No veo ninguna otra diferencia evidente en el lenguaje.
Como mínimo, se eliminaron finalmente un montón de funciones telescópicas y, lo más importante, se añadió una biblioteca estándar con un gran número de clases útiles.
Como mínimo, finalmente se deshizo de un montón de funciones telescópicas y, lo más importante, se añadió una biblioteca estándar con un gran número de clases útiles.
especialmente Object.mqh
justo de los libros que citas sin suerte...patrón brillante :-)
El tema no es sobre lo bien que has dominado el curso de POO y has aprendido a defenderlo... en mi opinión es una mierda de maestría
De todas formas, coged los libros de texto y acudid a la escuela mañana.