Discussion de l'article "Architecture événementielle en MQL5 : Comment transformer un Expert Advisor en un système de trading à part entière"

Nouveau commentaire
 

Un nouvel article Architecture événementielle en MQL5 : Comment transformer un Expert Advisor en un système de trading à part entière a été publié :

Cet article est consacré à l'architecture événementielle de MQL5 et décrit la transition du modèle monolithique OnTick au traitement distribué. Nous examinerons les événements prédéfinis et personnalisés, les services, l’échange de messages entre programmes, ainsi que les erreurs d'architecture courantes. Un exemple pratique montre comment organiser les interactions entre les indicateurs et un Expert Advisor afin de réduire la charge, d'améliorer la lisibilité et de simplifier la maintenance.

Lors du développement d'un Expert Advisor en MQL5, beaucoup de personnes privilégient la solution la plus évidente : elles placent toute la logique dans la méthode OnTick. Il est effectivement plus facile de commencer de cette manière. Cependant, cette approche a un coût caché. À mesure que le projet se développe, les règles de trading, la vérification des conditions, le traitement des ordres, la mise à jour des données, l'interface, les calculs et la journalisation sont tous combinés dans un seul gestionnaire. De ce fait, le code évolue jusqu'à atteindre un état où il n’est plus réellement maîtrisable et où il ne tient plus que par hasard. Tout changement à un endroit commence à affecter des parties complètement différentes du système. Vous modifiez le panneau visuel – et soudain, la logique de trading cesse de fonctionner. Vous modifiez le filtre d'entrée - une erreur apparaît dans le contrôle en arrière-plan. Un tel Expert Advisor se transforme rapidement en un monolithe fragile, où la complexité grandit plus vite que la confiance du développeur.

MetaTrader 5 est bien plus qu'un simple flux de cotations. Son fonctionnement repose sur des événements. Le terminal reçoit continuellement des ticks, des signaux de minuterie, des actions des utilisateurs, des changements d'état de trading et des événements de profondeur de marché. Ces messages doivent être traités séparément. Pour ce faire, MQL5 propose différents gestionnaires, chacun ayant son propre domaine de responsabilité. OnTick est responsable des mises à jour du marché. OnTimer — pour les tâches périodiques et en arrière-plan. OnChartEvent — pour la réaction à l'interface graphique et aux actions de l'utilisateur. Lorsque la logique est répartie en fonction de sa finalité, le code cesse d'être encombré. Cela commence à ressembler à un système d'ingénierie bien structuré, où chaque module remplit sa fonction sans interférer avec celle de ses voisins.

Événements MQL5

Dans cet article, nous verrons comment passer du modèle « tout dans OnTick » à une architecture événementielle plus mature. Examinons le rôle des gestionnaires prédéfinis et des événements personnalisés, ainsi que celui des services qui ne sont pas liés à un graphique. Examinons de plus près les erreurs typiques qui compromettent l'architecture avant même que le travail ne commence réellement. L'idée principale est simple : lorsque MQL5 est utilisé conformément à sa finalité, il nous permet de construire non seulement des robots de trading, mais aussi de véritables systèmes applicatifs.


Auteur : MetaQuotes

 
Travailler dans un conseiller technique avec des indicateurs sans tampon : cela fera sans doute un bon exemple.
  
//+------------------------------------------------------------------+
//| Fonction de trading                                                   |
//+------------------------------------------------------------------+
void OnTrade()
  {
   Sleep(0);
//---
  }
//+------------------------------------------------------------------+
//| Fonction TradeTransaction                                        |
//+------------------------------------------------------------------+
void OnTradeTransaction(const MqlTradeTransaction& trans,
                        const MqlTradeRequest& request,
                        const MqlTradeResult& result)
  {
   Sleep(0);
//---
  }
Pourquoi ?
  
            if(!cTrade.PositionClose(cPosition.Ticket()))
              {
               PrintFormat("Error close Sell position: %d", GetLastError());
               return;
              }
Il semblerait que cTrade contienne une instruction de sortie en cas d'erreur.
 
fxsaber #:
Travailler dans un conseiller technique avec des indicateurs sans tampon : cela fera sans doute l'affaire comme exemple.


Dans cet exemple, la mise à jour des données du symbole est effectuée de manière stricte (il serait préférable d'utiliser MQL_TESTER).

void OnTick()
  {
//---
   if(BuySignal)
     {
      cSymbol.Refresh();
      cSymbol.RefreshRates();


Mais aucune vérification n’est effectuée pour s’assurer que les valeurs calculées à partir des événements de signal et de tick sont bien à jour. Et c’est là un véritable problème.


On peut l'atténuer grâce à des appels asynchrones à OrderSend, mais pas la résoudre. C'est pourquoi, même dans un tel exemple, il faut en plus transmettre, dans l'événement ChartEvent, les données du tick au cours duquel l'événement a été généré.

 
Super, le type de service des programmes MQL5 est vraiment sous-estimé.
 
C'est un excellent exemple, merci.
Nouveau commentaire