Construimos un asesor usando módulos individuales

Andrei Novichkov | 13 noviembre, 2019

Introducción

Durante el desarrollo de indicadores, asesores y scripts, el desarrollor se ve obligado a crear constantemente fragmentos de código terminados, que no tienen relación directa con la estrategia de trading. Por ejemplo, puede tratarse del horario de trabajo del asesor, de un día, una semana, un mes. Como resultado del desarrollo, proyectaremos un objeto independiente que interactuará con la principal lógica comercial y otros componentes, utilizando su sencilla interfaz. Si el desarrollador emplea un mínimo de esfuerzo, este horario se podrá usar en posteriores trabajos con los asesores, indicadores, etc, sin realizar casi modificaciones. En el presente artículo, hemos tratado de sistematizar la proyección de asesores "por bloques", y también hemos analizado la interesante capacidad que obtendremos como resultado. El artículo se ha escrito pensando en desarrolladores principiantes.

Cómo sucede ahora

Comenzaremos por intentar comprender qué aspecto puede tener un asesor así, proyectado "sobre la marcha" y de qué partes / componentes / módulos puede constar. ¿De dónde pueden proceder estos componentes? La respuesta es clara y comprensible: durante el desarrollo constante del trabajo, el desarrollador se ve obligado una y otra vez a proyectar componentes aparte con funcionalidad semejante e incluso coincidente.

Salta rápidamente a la vista que preparar cada vez un nuevo trailing (por ejemplo) supone un gasto inútil de tiempo. En general, el traling de cualquier asesor tendrá siempre las mismas tareas y aproximadamente los mismos parámetros de entrada. Por eso, el desarrollador debe proyectar el trailing una sola vez, y luego colocarlo en todos los asesores que tienen esta necesidad, invirtiendo en ello el mínimo esfuerzo. Lomismo podemos decir de multitud de otros componentes: el ya mencionado componente de horario, diferentes filtros y de noticias, módulos que combinan diversas funciones comerciales y otros.

Como resultado, obtendremos un asesor bastante caótico, preparado a partir de una especie de puzle conformado por diferntes módulos / bloques programáticos. Los módulos intercambian información entre sí y con la "parte central" del asesor, la "estrategia" que toma las decisiones. Vamos a representar una posible variante de interacción de varios módulos:

Nos ha salido un esquema bastante confuso. Y eso que solo hemos usado tres módulos y dos manejadores del asesor: OnStart y OnTick. Si complicamos al asesor, como suele suceder, las conexiones internas se harán todavía más complejas. Resulta complicado corregir y mejorar un asesor así, y si surge la necesidad de quitar / incluir otro módulo, esto causará no pocos problemas. Además, la depuración primaria y la búsqueda de errores tampoco serán sencillas. Uno de las causas de estas complicaciones se encuentra en las conexiones proyectadas sin sistematización alguna. Debemos prohibir a los módulos relacionarse entre ellos y con los manejadores del asesor en cuanto surja cierta necesidad, y aparecer en cierto orden de inmediato:

• Todos los módulos se crean en OnInit.
• La lógica del asesor se encuentra en OnTick.
• Los módulos intercambian información solo con OnTick.
• Si hay necesidad de ello, los módulos son eliminados en OnDeinit.

Un cambio casi insignificante en el diseño conferirá a la estructura del asesor un aspecto más visual y comprensible a nivel intuitivo. La nueva estructura se asemeja ahora un poco al resultado del uso del patrón "Observer", aunque las diferencias de esta estructura con respecto a la mencionada no nos de pie a sacar tales conclusiones. Vamos a analizar a continuación cómo podemos mejorar el diseño y los cambios que esto acarreará.

Asesor para los experimentos

Para procesar nuestras ideas, necesitaremos un asesor sencillo. No vamos a hacerlo muy complejo, ya que lo necesitamos con fines exclusivamente didácticos. El asesor abrirá una orden de venta, si la vela anterior ha sido bajista. Proyectaremos el asesor usando la estructura de módulos. El primer módulo será el comercial:

class CTradeMod {
public:
   double dBaseLot;
   double dProfit;
   double dStop;
   long   lMagic;
   void   Sell();
   void   Buy();
};

void CTradeMod::Sell()
{
  CTrade Trade;
  Trade.SetExpertMagicNumber(lMagic);
  double ask = SymbolInfoDouble(Symbol(),SYMBOL_ASK);
  Trade.Sell(dBaseLot,NULL,0,ask + dStop,ask - dProfit);
} 

void CTradeMod::Buy()
{
  CTrade Trade;
  Trade.SetExpertMagicNumber(lMagic);
  double bid = SymbolInfoDouble(Symbol(),SYMBOL_BID);
  Trade.Buy(dBaseLot,NULL,0,bid - dStop,bid + dProfit);
} 

El módulo se ejecutará en forma de clase con campos y métodos abiertos. Por el momento, no necesitamos que el método Buy() esté implementado, pero nos hará falta más adelante. El valor de los campos aparte es obvio: volumen, niveles comerciales, número mágico. También resulta comprensible cómo usar el módulo: lo creamos y luego llamamos al método Sell() cuando aparezca la señal de entrada.

En el asesor se incluirá un módulo más:

class CParam {
public:
   double dStopLevel;      
   double dFreezeLevel;   
    CParam() {
      new_day();      
    }//EA_PARAM()
    void new_day() {
      dStopLevel   = SymbolInfoInteger(Symbol(),SYMBOL_TRADE_STOPS_LEVEL) * Point();
      dFreezeLevel = SymbolInfoInteger(Symbol(),SYMBOL_TRADE_FREEZE_LEVEL) * Point();
    }//void new_day()
};

...
input int MaxSpread = 100;
...
OnTick()
 {
   if(ask - bid > MaxSpread * Point() ) return;
....
 }

Está claro que este fragmento es totalmente ineficaz. Pero si colocamos todos los parámetros de entrada (y no solo de entrada) que requieren actualización y transformación en un módulo aparte (aquí se trataría de MaxSpread * Point() ), así no llenaremos de código innecesario el espacio global, logrando de esta forma controlar y gestionar su estado con facilidad, como se hace en el módulo CParam con los valores stops_level y freeze_level.

Es posible (y esto sería más correcto) no hacer en este y otros módulos los campos abiertos, sino prever getters para ellos. Aquí, esto se hace para simplifcar el código al máximo, pero si implementamos un proyecto real, la presencia de un getter sería más que deseable.

Además, es totalmente posible que, concretamente para el módulo CParam, merezca la pena hacer una excepción y apartarnos de las normas, permitiendo recurrir a este módulo no solo al manejador OnTick(), sino a todos los demas módulos y manejadores.

Y al fin, el bloque de parámetros de entrada y los manejadores del asesor:

input double dlot   = 0.01;
input int    profit = 50;
input int    stop   = 50;
input long   Magic  = 123456;

CParam par;
CTradeMod trade;

int OnInit()
  {  
   trade.dBaseLot = dlot;
   trade.dProfit  = profit * _Point;
   trade.dStop    = stop   * _Point;
   trade.lMagic   = Magic;
   
   return (INIT_SUCCEEDED);
  }
  
void OnDeinit(const int reason)
  {
  }

void OnTick()
  {
   int total = PositionsTotal(); 
   ulong ticket, tsell = 0;
   ENUM_POSITION_TYPE type;
   double l, p;
   for (int i = total - 1; i >= 0; i--) {
      if ( (ticket = PositionGetTicket(i)) != 0) {
         if ( PositionGetString(POSITION_SYMBOL) == _Symbol) {
            if (PositionGetInteger(POSITION_MAGIC) == Magic) {
               type = (ENUM_POSITION_TYPE)PositionGetInteger(POSITION_TYPE);
               l    = PositionGetDouble(POSITION_VOLUME);
               p    = PositionGetDouble(POSITION_PRICE_OPEN);
               switch(type) {
                  case POSITION_TYPE_SELL:
                     tsell = ticket;    
                     break;
               }//switch(type)
            }//if (PositionGetInteger(POSITION_MAGIC) == lmagic)
         }//if (PositionGetString(POSITION_SYMBOL) == symbol)
      }//if ( (ticket = PositionGetTicket(i)) != 0)
   }//for (int i = total - 1; i >= 0; i--)
   if (tsell == 0) 
      {
        double o = iOpen(NULL,PERIOD_CURRENT,1); 
        double c = iClose(NULL,PERIOD_CURRENT,1); 
        if (c < o) 
          {
            trade.Sell();
          }   
      }                         
  }

El asesor inicializa los módulos en el manejador OnInit(), y después recurre a ellos solo desde el manejador OnTick(). En OnTick(), el asesor ejecuta un ciclo por las posiciones abiertas, con objeto de comprobar si la posición necesaria está ya abierta. Si la posición aún no está abierta, el asesor la abre al darse la señal.

Merece la pena notar que el manejador OnDeinit(const int reason) aún está vacío. Los módulos se crean de tal forma que no requieren eliminación explícita. Además, todavía no hemos involucrado el módulo CParam, porque las comprobaciones al abrir una posición aún no se realizan. Pero si dichas comprobaciones se efecturan, el módulo CTradeMod podría requerir acceso al módulo CParam, y el módulo se vería obligado a responder a la pregunta mencionada anteriormente: ¿debemos usar el módulo CParam como excepción a las normas ya aplicadas? No obstante, si observamos con mayor detenimiento, esto no resulta necesario, por lo menos en el caso que nos ocupa.

Vamos a analizar este punto con más detalle. El módulo CTradeMod podría necesitar los datos del módulo CParam para comprobar los niveles de Stop Loss y Take Profit, así como el volumen de la posición abierta. Pero esta comprobación también se puede realizar en el punto de la toma de decisiones sobre la apertura de una posición: si los niveles y el volumen no superan la comprobación, tampoco necesitaremos abrir nada. Esto conlleva el traslado de la comprobación al manejador OnTick(). En este caso, dado que los valores de los niveles comerciales y el volumen se han establecido en los parámetros de entrada, la comprobación se puede realizar una vez en el manejador OnInit(), y si finiliza sin éxito, la inicialización de todo el asesor se deberá finalizar con error. Bien, como podemos ver, los módulos CTradeMod y CParam pueden actuar de forma independiente. De la misma forma sucederá en la mayoría de los asesores: los módulos independientes actúan a través del manejador OnTick() y no saben nada el uno sobre el otro. Pero, ¿en qué casos se hace imposible respetar esta condición? Lo veremos más tarde.

Comencemos las mejoras

Salta a la vista de inmediato el amplio ciclo de iteración de posiciones en el manejador OnTick(). Este segmento de código es necesario si el manejador no quiere que el asesor:

1. continúe abriendo posiciones si la señal de entrada aún no ha tenido tiempo de desvancerse,
2. detecte órdenes ya colocadas después de una interrupción en el funcionamiento,
3. posiblemente recopile algunas estadísticas actuales, como el volumen total de las posiciones abiertas o la reducción máxima.

El valor de este ciclo aumentará todavía más en el caso de que el asesor use la promediación o una cuadrícula. ¿Y cómo arreglárnoslas sin él cuando se usan niveles comerciales virtuales? Como cierre a lo dicho, podemos sacar la conclusión de que debemos crear un módulo aparte usando como base este fragmento de código. En el caso más sencillo, se trataría de un módulo que simplemente detectaría las posiciones con un determinado número mágico y comunicaría este hecho de cierta forma. En el caso complejo, este módulo podría constituir por sí mismo un "centro" que incluyese módulos mas sencillos, por ejemplo, los módulos de registro de logs y los módulos de estadística. En este caso, el asesor comenzará a adquirir la apreciada estructura "de árbol" con los manejadores OnInit() y OnTick() en la base. Veamos el aspecto que podría tener un módulo así:

class CSnap {
public:
           void CSnap()  {
               m_lmagic = -1; 
               m_symbol = Symbol();               
           }
   virtual void  ~CSnap() {}   
           bool   CreateSnap();
           long   m_lmagic;
           string m_symbol;
};

bool CSnap::CreateSnap() {
   int total = PositionsTotal(); 
   ulong ticket;
   ENUM_POSITION_TYPE type;
   double l, p;
   for (int i = total - 1; i >= 0; i--) {
      if ( (ticket = PositionGetTicket(i)) != 0) {
         if (StringLen(m_symbol) == 0 || PositionGetString(POSITION_SYMBOL) == m_symbol) {
            if (m_lmagic < 0 || PositionGetInteger(POSITION_MAGIC) == m_lmagic) {
               type = (ENUM_POSITION_TYPE)PositionGetInteger(POSITION_TYPE);
               l    = PositionGetDouble(POSITION_VOLUME);
               p    = PositionGetDouble(POSITION_PRICE_OPEN);
               switch(type) {
                  case POSITION_TYPE_BUY:
// ???????????????????????????????????????
                     break;
                  case POSITION_TYPE_SELL:
// ???????????????????????????????????????
                     break;
               }//switch(type)
            }//if (lmagic < 0 || PositionGetInteger(POSITION_MAGIC) == lmagic)
         }//if (StringLen(symbol) == 0 || PositionGetString(POSITION_SYMBOL) == symbol)
      }//if ( (ticket = PositionGetTicket(i)) != 0)
   }//for (int i = total - 1; i >= 0; i--)
   return true;
}

El código no es complicado, pero topamos con un problema. ¿De qué forma y a quién precisamente debe transmitir el módulo la información obtenida? ¿Qué debemos registrar en las líneas que contienen los símbolos en el último fragmento de código? Podría parecer que todo es sencillo. Llamamos en el manejador OnTick() el método CreateSnap(), que ejecuta el trabajo guardando los resultados en los campos de la clase CSnap. A continuación, el manejador comprueba los campos y saca ciertas conclusiones.

Sí, así puede hacerse en el caso más simple. Pero, ¿qué hacemos cuando debamos procesar los parámetros de cada posición por separado, por ejemplo, para calcular el valor medio ponderado? En este caso, necesitaremos un enfoque más universal, capaz de transmitar los datos al siguiente objeto para el procesamiento. Y para ello, deberemos prever en la clase CSnap un puntero a este objeto:

CStrategy* m_strategy;

     bool SetStrategy(CStrategy* strategy) {
              if(CheckPointer(strategy) == POINTER_INVALID) return false;
                 m_strategy = strategy;
                 return true;
              }//bool SetStrategy(CStrategy* strategy)   

Hemos elegido este nombre para el objeto CStrategy, de forma que en él se puedan tomar decisiones de entrada, y posiblemente otras decisiones. Por consiguiente, este objeto puede determinar la estrategia de todo el asesor.

Ahora, el conmutador switch en el método CreateSnap() tendrá el aspecto que sigue:

               switch(type) {
                  case POSITION_TYPE_BUY:
                     m_strategy.OnBuyFind(ticket, p, l);
                     break;
                  case POSITION_TYPE_SELL:
                     m_strategy.OnSellFind(ticket, p, l);
                     break;
               }//switch(type

Obviamente, en caso necesario, el código se puede completar fácilmente con conmutadores para las órdenes pendientes y las llamadas de los métodos correspondientes. Además, se puede modificar con mucha facilidad el método para recopilar una gran cantidad de información. Posiblemente merezca la pena hacer el método CreateSnap() virtual, teniendo en cuenta con ello las potenciales posibilidades de herencia de la clase CSnap. Pero esto no resulta elemental para nosotros en el caso actual, por lo que nos limitaremos a implementar un código más sencillo para el módulo actual.

Notemos que es muy probable que el puntero a dicho objeto (en nuestro caso, se trata del puntero CStrategy*) resulte útil no solo para el módulo analizado. La potencial necesidad de la conexión del módulo con la lógica de funcionamiento del asesor puede surgir en cualquier módulo que ejecute cálculos activos. Por eso, vamos a sacar el campo correspondiente y el método de inicialización a la clase básica:

class CModule {
   public:
      CModule() {m_strategy = NULL;}
     ~CModule() {}
     virtual bool SetStrategy(CStrategy* strategy) {
                     if(CheckPointer(strategy) == POINTER_INVALID) return false;
                     m_strategy = strategy;
                     return true;
                  }//bool SetStrategy(CStrategy* strategy)   
   protected:   
      CStrategy* m_strategy;  
};

public:
   const string GetName() const {return m_sModName;}
protected:
         string m_sModName;

El método retornaría el nombre del módulo que podría usarse para realizar el diagnóstico, la depuración, o en algún panel informativo.

Ahora, vamos a ver cómo podríamos implementar la clase CStrategy, tan importante para nosotros:

La estrategia del asesor

Anteriormente, hemos escrito que debe tratarse del objeto que tome las decisiones sobre las entradas. Pero entonces, significa que también puede tomar decisiones acerca de las salidas, las modificaciones, los cierres parciales, etcétera. Por eso, le hemos dado el nombre correspondiente. Además, resulta obvio que no puede de ninguna forma implementarse como módulo, ya que es muy importante que el objeto que tome la decisión se diferencie en cada asesor. En caso contrario, el desarrollador se arriesga a obtener simplemente un asesor idéntico al ya desarrollado. Por eso, no lograremos desarrollar e incluir una vez un objeto así en los demás asesores, como hacíamos con los módulos. Pero, por otra parte, no nos hace falta: iremos por otro camino. Comenzaremos el desarrollo por la clase básica, usando lo que ya conocemos:

class CStrategy  {
public:
   virtual  void    OnBuyFind  (ulong ticket, double price, double lot) = 0;
   virtual  void    OnSellFind (ulong ticket, double price, double lot) = 0;       
};// class CStrategy

Todo es muy sencillo. Necesitábamos dos métodos para la llamada en el caso de que el método CreateSnap() detectara las posiciones necesarias; ahora han sido añadidos. La clase CStrategy se ha ejecutado como abstracta, mientras que los métodos han sido declarados como virtuales. Esto es totalmente lógico y está completamente justificado, puesto que ya hemos analizado que este objeto debe variar de un asesor a otro. Por consiguiente, la clase básica puede ser utilizada solo para la herencia, mientras que sus métodos serán redefinidos.

Ahora queda añadir el archivo CStrategy.mqh al archivo CModule.mqh:

#include "CStrategy.mqh"

...y podremos considerar que la carcasa del asesor ha sido construida "a grandes rasgos", por lo que podremos ocuparnos de su posterior mejora.

Mejorando la estrategia del asesor

Con la ayuda de los métodos virtuales mostrados, el objeto CSnap recurre al objeto CStrategy. No obstante, en el objeto CStrategy tendrán que existir otros métodos. Recordemos que el objeto de la estrategia toma las decisiones. Por consiguiente, deberá dar recomendaciones sobre la entrada si detecta la señal correspondiente, y también efectuar dicha entrada. Por ello, tendrán que existir métodos que obliguen al objeto CSnap a llamar a su método CreateSnap(), etcétera. Vamos a añadir algunos de estos métodos a la clase CStrategy:

   virtual  string  Name() const     = 0;
   virtual  void    CreateSnap()     = 0;  
   virtual  bool    MayAndEnter()    = 0;  
   virtual  bool    MayAndContinue() = 0;       
   virtual  void    MayAndClose()    = 0;

Por supuesto, debemos recordar que esta lista es sumamente condicional y puede ser modificada y corregida de un asesor a otro. Describamos estos métodos brevemente:

• Name()                — Retorna el nombre de la estrategia.
  
• CreateSnap()        — Llama al mismo método del objeto CSnap.
• MayAndEnter()      — comprueba la presencia de una señal de entrada, y entra si esta existe.
  
• MayAndContinue() — comprueba la existencia de una señal de entrada y entra de nuevo
  
• MayAndClose()      — comprueba la existencia de una señal de salida y cierra todas las posiciones si existe tal señal.

virtual  bool    Initialize(CInitializeStruct* pInit) = 0;

class CInitializeStruct {};

class CRealStrat1 : public CStrategy   {
public:
   static   string  m_name;
                     CRealStrat1(){};
                    ~CRealStrat1(){};
   virtual  string  Name() const {return m_name;}
   virtual  bool    Initialize(CInitializeStruct* pInit) {
                        m_pparam = ((CInit1* )pInit).m_pparam;
                        m_psnap = ((CInit1* )pInit).m_psnap;
                        m_ptrade = ((CInit1* )pInit).m_ptrade;
                        m_psnap.SetStrategy(GetPointer(this));
                        return true;
                    }//Initialize(EA_InitializeStruct* pInit)
   virtual  void    CreateSnap() {
                        m_tb = 0;
                        m_psnap.CreateSnap();
                    }  
   virtual  bool    MayAndEnter();
   virtual  bool    MayAndContinue() {return false;}       
   virtual  void    MayAndClose()   {}
   virtual  bool    Stop()            {return false;}   
   virtual  void    OnBuyFind  (ulong ticket, double price, double lot) {}
   virtual  void    OnBuySFind (ulong ticket, double price, double lot) {}   
   virtual  void    OnBuyLFind (ulong ticket, double price, double lot) {}
   virtual  void    OnSellFind (ulong ticket, double price, double lot) {tb = ticket;}  
   virtual  void    OnSellSFind(ulong ticket, double price, double lot) {}   
   virtual  void    OnSellLFind(ulong ticket, double price, double lot) {}      
private:
   CParam*          m_pparam;
   CSnap*           m_psnap;  
   CTradeMod*       m_ptrade;   
   ulong            m_tb;            
};
static string CRealStrat1::m_name = "Real Strategy 1";

bool CRealStrat1::MayAndEnter() {
   if (tb != 0) return false;  
   double o = iOpen(NULL,PERIOD_CURRENT,1); 
   double c = iClose(NULL,PERIOD_CURRENT,1); 
   if (c < o) {
      m_ptrade.Sell();
      return true;
   }   
   return false;
} 

class CInit1: public CInitializeStruct {
public:
   bool Initialize(CParam* pparam, CSnap* psnap, CTradeMod* ptrade) {
   if (CheckPointer(pparam) == POINTER_INVALID || 
       CheckPointer(psnap)  == POINTER_INVALID) return false;   
      m_pparam = pparam; 
      m_psnap  = psnap;
      m_ptrade = ptrade;
       return true;
   }
   CParam* m_pparam;
   CSnap*  m_psnap;
   CTradeMod* m_ptrade;
};

CParam     par;
CSnap      snap;
CTradeMod  trade;

CStrategy* pS1;

int OnInit()
  {  
   ...
   pS1 = new CRealStrat1();
   CInit1 ci;
   if (!ci.Initialize(GetPointer(par), GetPointer(snap), GetPointer(trade)) ) return (INIT_FAILED);
   pS1.Initialize(GetPointer(ci));      
   return (INIT_SUCCEEDED);
  }
  

void OnDeinit(const int reason)
  {
      if (CheckPointer(pS1) != POINTER_INVALID) delete pS1;      
  }

void OnTick()
  {
      if (IsNewCandle() ){
         pS1.CreateSnap();
         pS1.MayAndEnter();
         
      }    
  }

enum CSTRAT {
   strategy_1 = 1,
   strategy_2 = 2
};

input CSTRAT strt  = strategy_1;

CSTRAT str_curr = -1;

int OnInit()
  {  
   ...
   if (!SwitchStrategy(strt) ) return (INIT_FAILED);
   ...       
   return (INIT_SUCCEEDED);
  }
  
void OnChartEvent(const int id,
                  const long &lparam,
                  const double &dparam,
                  const string &sparam)
  {
      if (id == CHARTEVENT_OBJECT_CLICK && StringCompare(...) == 0 ) {
         SwitchStrategy((CSTRAT)EDlg.GetStratID() );
      } 
  }  

bool SwitchStrategy(CSTRAT sr) {
   if (str_curr == sr) return true;
   CStrategy* s = NULL;
   switch(sr) {
      case strategy_1:
         {
            CInit1 ci;
            if (!ci.Initialize(GetPointer(par), GetPointer(snap), GetPointer(trade)) ) return false;
            s = new CRealStrat1();
            s.Initialize(GetPointer(ci));  
         }
         break;
      case strategy_2:
         {
            CInit2 ci;
            if (!ci.Initialize(GetPointer(par), GetPointer(snap), GetPointer(trade)) ) return false;
            s = new CRealStrat2();
            s.Initialize(GetPointer(ci));              
         }   
         break;
   }
   if (CheckPointer(pS1) != POINTER_INVALID) delete pS1;
   pS1 = s;    
   str_curr = sr;
   return true;
}

CStrategy* pS1;

Conclusión

Hemos proyectado un asesor usando los elementos de los patrones estándar de creación de proyectos "Observer" y "Facade". La descripción completa de estos patrones (y no solo de ellos) se puede encontrar aquí: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides "Design Patterns. Elements of Reusable Object-Oriented Software", un libro cuya lectura recomendamos encarecidamente.

Programas usados en el artículo: