OOP vs. programación procedimental - página 5

[Реter Konow]

Petros Shatakhtsyan:

He aquí una tarea sencilla (sería necesario escribir mucho para explicarla en detalle).

Todo sucede en OnTick(). Supongamos que comprobamos alguna condición y abrimos una orden. La condición no es importante, supongamos que es algún máximo o mínimo.

El robot, naturalmente, se sitúa en algún gráfico y obtiene cotizaciones de este símbolo. Está claro que no sólo tenemos una función OnTick, sino también otras funciones: OnTrade, OnTimer, funciones personalizadas, etc.

Por lo tanto, todas las variables que se comparten deben ser declaradas fuera de estas funciones al principio del código. Por ejemplo, el nombre del símbolo, la demanda, la oferta, el diferencial, el número de dígitos de la cotización, etc. Habrá docenas de ellos.

Este robot operará con un solo símbolo, es decir, donde se encuentre. Supongamos que hay 20 de estos gráficos y que vamos a instalar el mismo robot en todos ellos para operar simultáneamente para los 20 pares.

Pero no se trata de un robot de comercio multidivisa, como han señalado algunos operadores del Mercado.

Aquí tenemos que convertirlo en un robot multidivisa. Es decir, lo ponemos en cualquier gráfico (sólo en 1 gráfico) y abre operaciones para 20 pares. Así, lo lanzamos en el probador en el modo simple, y operará con aquellos pares que estén en Market Watch.

Así es como se implementará sin OOP. ¿Transformará todas las variables comunes en matrices de 20 elementos?

¿Y qué pasa con las funciones que se llamarán simultáneamente para todos los pares?

No se puede prescindir de la OOP. :)

P.S. Quiero hacer notar, que no tengo educación rusa, y por eso escribí largo y no tuve tiempo de leer varias páginas.

Para crear un motor multidivisa, debes escribir inicialmente un motor multidivisa, no rediseñar un robot personalizado para un par.

El método para crear un bot multidivisa no requiere el uso de OOP. Podemos escribir un bloque de código que tome los ticks de todos los pares de divisas y aplique las mismas funciones de análisis y colocación de órdenes en todas partes. Las propias funciones de orden contendrán variables cuyos valores cambiarán dependiendo del par. Estos valores serán modificados por el bloque que recibe los ticks.

[Dmitry Fedoseev]

Реter Konow:
Sería deseable que se llevara a cabo una tarea concreta. Esta descripción no es muy clara. En mi práctica, el algoritmo no cambia cuando cambian los parámetros externos. Se hace universal de antemano para cualquier valor de estos parámetros. Por lo tanto, no está muy claro lo que quiere decir. Descríbalo con un ejemplo concreto.

Por ejemplo, hay que meter 100 variantes de trailing stop en un Asesor Experto. Cuando se programa de forma procedimental, se obtiene un lío como este:

if(Trailing_01_ON){
    Trailing1();
}
if(Trailing_02_ON){
    Trailing2();
}
...
...
...
if(Trailing_99_ON){
    Trailing99();
}

100 fragmentos de código idénticos. Cuando el programa se está ejecutando, suele incluir sólo un trailing stop. Los 99 if restantes sólo consumen recursos.

Ahora la variante OOP. Durante la inicialización del Asesor Experto, escalamos el array con punteros según el número de pistas, creamos objetos sólo para las pistas incluidas. Como resultado, el siguiente código funcionará siempre:

for(int i=0;i<cnt;i++){
   p[i].Main();
} 

Si se activa un trailing stop, entonces cnt=1, es decir, no hay nada innecesario.

[Petros Shatakhtsyan]

Dmitry Fedoseev:

La pregunta más relevante aquí no es "cómo" sino "por qué". ¿Por qué codificar algo que ya está implementado en el terminal - simplemente abrir el número necesario de gráficos y atribuirles un EA? Además, los parámetros deben ser diferentes para los distintos símbolos y plazos.

No se ha implementado nada en el terminal. En primer lugar, sólo se abre un gráfico en lugar de 20; en segundo lugar, en el probador no podrá probar muchos pares simultáneamente, considerando todas las posiciones abiertas.

No me digas que existe el modo "Todos los símbolos seleccionados en MarketWatch".

[Petros Shatakhtsyan]

Un programador que no entiende cómo se describe el concepto de "Objeto" puede considerarse un programador aficionado, y no conoce el arte de la programación moderna.

[Реter Konow]

Dmitry Fedoseev:

Por ejemplo, hay que meter 100 variantes de trailing stop en un Asesor Experto. Cuando se programa de forma procedimental, se obtiene un lío como este:

100 fragmentos de código idénticos. Cuando el programa se está ejecutando, normalmente sólo incluirá un trailing stop. Los 99 ifs restantes sólo consumirán recursos.

Ahora la variante OOP. Durante la inicialización del Asesor Experto, escalamos el array con punteros según el número de barras de arrastre, creamos objetos sólo para las barras de arrastre habilitadas. Como resultado, el siguiente código funcionará siempre:

Si se habilita una barra de arrastre, entonces cnt=1, es decir, no hay nada innecesario.

Este es un enfoque muy, muy extraño para resolver la tarea con trailingings en general. No debería haber tal tarea: 100 tipos diferentes de trailing stops y una función diferente para cada uno.

Es necesario comprimir estos tipos en una o más fórmulas, haciendo una función de trailing stop común. Eso es todo. Por supuesto, tendrá que trabajar con la materia gris, pero la OOP no tiene nada que ver...

[Dmitry Fedoseev]

Реter Konow:

Un enfoque muy, muy extraño del problema del trailing stop en su conjunto. No debería haber 100 tipos diferentes de trailing stops y una función diferente para cada uno.

Estos tipos deben ser comprimidos en una o varias fórmulas, y una función de arrastre común. Eso es todo. Por supuesto, tendrás que trabajar con materia gris, pero no tiene nada que ver con la POO...

Supongamos un trailing stop en MA, y hay decenas de ellos.

¿Y por qué comprimir algo cuando se puede vivir fácilmente?

[Реter Konow]

Dmitry Fedoseev:

Supongamos que se trata de MAs de arrastre, y hay varias docenas de ellas.

¿Y por qué hay que comprimir algo cuando se puede vivir con tranquilidad?

Resulta que la esencia de su argumento a favor de la OOP se basa en facilitar una decisión inherentemente ridícula. Es un argumento dudoso...

¿Por qué decenas de funciones de arrastre diferentes? ¿Es difícil para un programador OOP serio escribir una universal?

[Dmitry Fedoseev]

Реter Konow:

Resulta que la esencia de su argumento a favor de la POO se basa en facilitar una solución inherentemente ridícula. Dudoso argumento...

¿Por qué es ridículo de repente?

¿Cómo de ridículo sería utilizar 100 ifs?

[Реter Konow]

Dmitry Fedoseev:

¿Por qué es ridículo de repente?

Sería ridículo utilizar 100 iffos.

No es necesario utilizar 100 iffos. Es necesario resolver el problema de manera más eficiente y hacer una sola función con ajustes posteriores a los diferentes parámetros.

[Dmitry Fedoseev]

Реter Konow:
No es necesario utilizar 100 ifofs. Hay que resolver la tarea de forma más eficiente y hacer una función con unidad de arrastre que se adapte a diferentes parámetros.

¿Y cómo vas a hacer que el trailing stop se adapte a diferentes parámetros? Todavía habrá algunas ramas del algoritmo que con algunas combinaciones de parámetros nunca se ejecutarán.