Discusión sobre el artículo "Desarrollamos un Asesor Experto multidivisas (Parte 1): Funcionamiento conjunto de varias estrategias comerciales" - página 2

Nuevo comentario
 
fxsaber #:

No hará daño, al 100%. Es sólo una entidad innecesaria. OOP arquitectónicamente sigue el principio de lo general a lo particular. Usted ha hecho el general (clase base) "privado". Aunque todo lo que se llama allí es CStrategy::Tick().

Este es el enfoque que tomé aquí. Supongamos que podemos crear una jerarquía lineal Clase base -> Heredera1 -> Heredera2 -> Heredera3. Las clases herederas complican progresivamente a su clase padre, pero no hay ramificación del árbol de herencia en ninguna parte, es decir, todas las clases tienen un único heredero sucesivo. Entonces, si vamos a crear objetos reales de sólo unas pocas clases que serán las sucesoras de Inheritor3, y todo el código de las clases padre es suficientemente compacto, haremos una clase base de una vez, incluyendo el contenido de las tres primeras sucesoras.

En este artículo, la clase base realmente, en general, sólo contiene CStrategy::Tick(). Pero más adelante está previsto añadir código más general para todas las estrategias.

 
fxsaber #:

Parece ser un error del compilador que no jura esta firma de método cuando se llama así.

Aqui, segun tengo entendido, se debe a que los punteros en MQL5 no son lo mismo que los punteros en C++. Por eso esta variante es adecuada.

 
fxsaber CObject.

No se utiliza.


Me he dado cuenta de que es una práctica bastante común heredar de CObject.

No entiendo muy bien, ¿qué es exactamente lo que no se utiliza, aunque podría ser?

Heredar de CObject sólo se hace para poder utilizar posteriormente Save() y Load()

 
Yuriy Bykov #:

No acabo de entender, ¿qué es exactamente lo que no se utiliza, aunque podría ser?

Daré el código completo.

class CObject
  {
private:
   CObject          *m_prev;               // elemento anterior de la lista
   CObject          *m_next;               // siguiente elemento de la lista

public:
                     CObject(void): m_prev(NULL),m_next(NULL)            {                 }
                    ~CObject(void)                                       {                 }
   //--- métodos para acceder a datos protegidos
   CObject          *Prev(void)                                    const { return(m_prev); }
   void              Prev(CObject *node)                                 { m_prev=node;    }
   CObject          *Next(void)                                    const { return(m_next); }
   void              Next(CObject *node)                                 { m_next=node;    }
   //--- métodos para trabajar con ficheros
   virtual bool      Save(const int file_handle)                         { return(true);   }
   virtual bool      Load(const int file_handle)                         { return(true);   }
   //--- método de identificación del objeto
   virtual int       Type(void)                                    const { return(0);      }
   //--- método de comparación de los objetos
   virtual int       Compare(const CObject *node,const int mode=0) const { return(0);      }
  };

Brevemente hablando, esta clase está pensada para formar y trabajar con listas, incluyendo una posible ordenación.

La herencia de CObject se hace sólo para poder utilizar más adelante Save() y Load()

de un cañón a los gorriones. ¿Por qué no añadir estos dos métodos virtuales a CStrategy?

 
fxsaber #:

De un cañón sobre gorriones. ¿Por qué no añadir estos dos métodos virtuales a CStrategy?

Sí, estoy de acuerdo. Añadiré métodos de guardado a CStrategy y al resto de clases base en lugar de heredar de CObject

 
Yuriy Bykov #:

Haces la conversión OOP de SimpleVolumes.mq5 clásico (entrada + sin OOP) a SimpleVolumesStartegy.mqh.

Por qué no hiciste SimpleVolumes.mq5 vía #include SimpleVolumesStartegy.mqh ?

 
fxsaber #:

se puede ver claramente el engorro con las entradas debido a la OOP. Sería bueno eliminarlo.

Camuflado.

int OnInit() {
   expert.AddStrategy(new CSimpleVolumeStrategy(
                         magic_ + 1, "EURGBP", PERIOD_H1,
                         NormalizeDouble(0.34 * depoPart_, 2),
                         130, 0.9, 1.4, 231, 3750, 50, 600, 3)
                     );
   expert.AddStrategy(new CSimpleVolumeStrategy(
                         magic_ + 2, "EURGBP", PERIOD_H1,
                         NormalizeDouble(0.10 * depoPart_, 2),
                         159, 1.7, 0.8, 248, 3600, 495, 39000, 3)
                     );

   int res = expert.Init();   // Inicialización de todas las estrategias del Asesor Experto

   return(res);
}

Ya que empezaron a mostrar el trabajo de la cartera TC, sería bueno tratar la carga de la cartera (inputs) adecuadamente.

 
fxsaber #:

Haces una conversión OOP del clásico (entrada + no OOP) SimpleVolumes.mq5 a SimpleVolumesStartegy.mqh.

Por qué no hiciste SimpleVolumes.mq5 vía #include SimpleVolumesStartegy.mqh ?

Porque quería demostrar el proceso de transición de un EA normal (entrada + sin OOP), que está escrito sin el objetivo de usarlo en modo paralelo con diferentes configuraciones (este es el rol SimpleVolumes.mq5) a otro EA, en el que se puede hacer este uso paralelo (este es el rol SimpleVolumesExpert.mq5). Para este propósito necesitamos OOP-transformación en SimpleVolumesStartegy.mqh.

 
fxsaber #:

Desde que empezaron a mostrar el trabajo de la cartera de TC, sería bueno para hacer frente a la carga de la cartera (entradas) de manera competente.

Sin duda lo trataremos en las próximas partes. Todavía hay muchas cosas que tratar, por lo que no fue posible presentar todo a la vez.

Estoy muy agradecido por todos sus comentarios, porque ahora es el momento adecuado para ellos - para los artículos que estoy rehaciendo casi desde cero mi código escrito anteriormente durante los últimos años, que no ha sido limpiado y optimizado sin mucha necesidad. Así que el código hace su trabajo, pero hay algunos lugares que ya no son necesarios, pero no se han limpiado, así como algunos lugares donde, como se puede ver ahora, se puede simplificar el código o aplicar un enfoque arquitectónico diferente en general.

Idealmente, me gustaría llegar al nivel de automatización completa de la optimización y la selección de una buena cartera de parámetros de la estrategia utilizando sus excelentes bibliotecas.

 
Yuriy Bykov #:

Porque quería demostrar el proceso de pasar de un EA normal (entrada + sin OOP)

Lo tengo.
1234
Nuevo comentario