Règles de structure. Apprendre à structurer des programmes, explorer les possibilités, les erreurs, les solutions, etc. - page 7
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Je suggère de définir les modèles de conception de base :
1. Fonctionnel
2. modèle d'objet
3. Pilotage par les événements .
...
le type en
4. Composant
--
En général, tout programme (y compris celui que vous envisagez) peut être vu sous différents angles. // c'est compréhensible.
Lors de l'analyse initiale d'un projet, j'essaie de prendre en compte au moins 4 aspects :
1. Structurel : Organisation physique et logique du code du programme et de ses composants.
2. Fonctionnel (à ne pas confondre avec l'approche fonctionnelle du développement) : quelles tâches le programme résout (quel produit il produit), quelle est son utilisation, quel résultat il doit produire, etc.
3. Communicatif : quel type d'interface utilisateur le programme doit avoir, avec quels programmes il communique et comment, les protocoles de communication, etc...
4. Gestionnaire : comment le logiciel est géré, quels sont les réglages à effectuer, les degrés de liberté, etc.
Tous les aspects sont inextricablement liés, mais regarder sous ces différents angles (+ quelques autres) permet de ne pas manquer des subtilités importantes, et dans les premiers temps de ne pas bâcler quelque chose d'important aux conséquences considérables... )
...D'une manière générale, tout programme (y compris un programme conçu) peut être examiné sous différents angles. // c'est compréhensible...
Je suis tout à fait d'accord. C'est un principe philosophique général : étudier un phénomène sous différents angles...
Et j'essaie de répondre à la question "Que doit faire un programme et que ne doit-il pas faire ?" au début du développement. La première partie de la question relève du système (ici MTS), la deuxième partie n'en relève pas, elle est en dehors.
À mon avis, il est très important, quel que soit le modèle de conception, d'avoir une hiérarchie des éléments du modèle. La méthode déductive - "du général au particulier" - fonctionne alors bien, décomposant le modèle en ses blocs principaux et constitutifs.
Pour échanger des idées / apprendre les uns des autres, je propose de prendre un problème plus ou moins pratique et de le restructurer ensemble.
Par exemple, décrivez au moins la structure de base (ou plus précisément, les variantes de ces structures) pour un tel problème :
Il existe un conseiller expert écrit comme ceci (par exemple, pour tester une idée de trading). Supposons que l'idée dans le testeur de stratégie (chez le client) montre des résultats prometteurs. Maintenant, nous devons réécrire le conseiller expert pour le rendre plus facile à développer, et en particulier, pour le doter d'un panneau de contrôle graphique.
Il est souhaitable soit de rendre le panneau commutable (pour l'optimisation dans le testeur), soit de déplacer toute la réalisation "non graphique" de l'EA dans un fichier enfichable (.mqh), qui peut alors être connecté à l'interface graphique sans modification (pour exclure) les différences de fonctionnement des versions "testeur" et "graphique".
J'aimerais entendre et lire les considérations sur la structuration d'un tel projet, en particulier sur l'implémentation du modèle de contrôle événementiel dans un tel projet. Supposons que la double mise en œuvre (testeur + panneau) soit une exigence stricte du client (c'est-à-dire que le projet doit être réalisé de n'importe quelle manière, vous pouvez seulement choisir la méthode de mise en œuvre).
On essaie ?
Je pense qu'il est évident que le panneau de contrôle Expert Advisor et l'Expert Advisor sont deux modules complètement différents dans un même programme. Il faudrait donc les séparer pour que chaque partie soit indépendante de l'autre. Cela signifie que si vous modifiez une partie d'un conseiller expert (par exemple, un changement dans la logique de placement des ordres), vous ne devez pas modifier la logique du panneau et vice versa (changement dans l'interface du panneau - pas besoin de modifier la logique du conseiller expert). La première chose qui vient à l'esprit est la création d'une interface unifiée par laquelle le panel et le conseiller expert peuvent communiquer. Mais malheureusement, les créateurs de MQL5 n'ont pas envisagé la possibilité de créer des liens horizontaux, et par conséquent, décrire l'interface entre eux au moyen de MQL5 ne fonctionnera pas. Il reste alors la voie de l'intégration verticale. Un conseiller expert doit être hérité d'une classe de base, qui contient à son tour des méthodes et des données suffisantes pour interagir avec le panneau. Cela signifie que tout EA hérité de la classe de base sera également capable d'afficher et d'interagir avec le panneau. La mise en œuvre des méthodes, responsables de l'interaction avec le panneau, ne doit pas être déléguée aux descendants, mais doit être effectuée dans les coulisses de la classe de base, c'est-à-dire que le message "Descendant ! Si vous voulez interagir avec le panneau, vous devez appeler telle ou telle de mes méthodes avec tels ou tels paramètres" ne fonctionne pas du tout. Idéalement, tout Expert Advisor dérivé qui hérite de la classe de base devrait simplement effectuer des transactions de manière pratique et ses actions seront automatiquement affichées sur ce panneau.
La manière d'organiser une classe de base universelle est un autre sujet intéressant. Plusieurs années de pratique en la matière m'ont finalement conduit à mon schéma universel. Elle s'est révélée transparente et universelle. Si vous êtes intéressé, je peux vous fournir son organigramme de base (ha ha, dessiner des organigrammes est une activité très utile après tout). Mais de toute façon, chacun a sa propre façon de faire, et une bonne solution pour l'un ne sera pas une bonne solution pour un autre.
Si cela vous intéresse, je peux vous donner un schéma de principe (ha-ha, dessiner des schémas de principe est une activité utile après tout).
La première chose qui vient à l'esprit est la création d'une interface unifiée par laquelle le panel et l'EA peuvent échanger des données. 2.
Malheureusement, les créateurs de MQL5 n'ont pas prévu la possibilité de créer des liens horizontaux, et par conséquent, il est impossible de décrire l'interface entre eux à l'aide des outils de MQL5.
1. sans ambiguïté.
2. Et les événements personnalisés ? C'est tout à fait horizontal et universel.
3. alors la voie de l'intégration verticale demeure. Un Expert Advisor doit être hérité d'une classe de base, qui contient à son tour des méthodes et des données suffisantes pour interagir avec le panneau. Cela signifie que tout conseiller expert hérité de la classe de base a également la capacité d'afficher et d'interagir avec le panneau. La mise en œuvre des méthodes, responsables de l'interaction avec le panneau, ne doit pas être déléguée aux descendants, mais doit être effectuée dans les coulisses de la classe de base, c'est-à-dire que le message "Descendant ! Si vous voulez interagir avec le panneau, vous devez appeler telle ou telle de mes méthodes avec tels ou tels paramètres" ne fonctionne pas du tout. Idéalement, tout Expert Advisor dérivé hérité d'une classe de base devrait simplement effectuer des transactions de manière pratique, tandis que ses actions seraient automatiquement affichées sur ce panneau.
Comme je ne suis pas d'accord avec le point 2, je ne creuse pas encore cette variante.
--
J'ai une alternative, que je trouve très intéressante (variante avec panneau "déconnectable"). Faites le panneau sous la forme d'un indicateur. Si votre conseiller expert est dans le testeur de stratégie, il ne charge tout simplement pas le panneau. Le bonus supplémentaire est que le panneau fonctionne dans un fil différent, ce qui laisse plus de ressources pour le conseiller expert.
En ce qui concerne la polyvalence du panneau, je ne vois pas d'obstacle majeur à ce que le panneau soit entièrement configurable via un fichier ini. En d'autres termes, vous pouvez y prescrire absolument toutes les données nécessaires pour créer n'importe quel panneau à partir d'un ensemble limité de composants visuels + les codes d'événements qu'ils doivent générer lors de l'interaction avec un utilisateur.
La manière d'organiser une classe de base universelle pour le commerce est un autre sujet intéressant. Plusieurs années de pratique à ce sujet m'ont finalement conduit à mon schéma universel. Il s'est avéré être transparent et universel. Si vous êtes intéressé, je peux vous montrer son schéma fonctionnel de base.....
1. sans ambiguïté.
Nahr Pourquoi ? L'universalisation excessive est aussi néfaste que l'optimisation prématurée.
Et lier les blocs d'un module par des événements... ...est lent et peu pratique.
Allez. Je suis en fait assez intéressé, et ça pourrait être utile en pratique.
Le cadre bleu représente les entités de la classe de base. Le cadre rouge représente les entités de la classe dérivée. Vous pouvez voir que la classe de base impose la définition de sa logique au descendant dans quatre méthodes. C'est ainsi qu'il réduit la description de toute stratégie à une description de seulement quatre situations :
1. Si toutes les règles d'ouverture d'une position longue ont été respectées, la position longue est ouverte par la méthode InitBuy().
2. Si toutes les règles de clôture de la position longue sont respectées, la position longue est clôturée à l'aide de la méthode SupportBuy().
3. si toutes les règles d'ouverture d'une position courte sont respectées, la position courte est ouverte à l'aide de la méthode InitSell().
4. Si toutes les règles de fermeture de la position courte sont respectées, la position courte est fermée par la méthode SupportSell().
Selon cette logique, la stratégie d'inversion n'est pas décrite dans une seule méthode (par exemple, fermeture longue ouverture courte), mais dans deux méthodes qui ne dépendent pas l'une de l'autre. Il s'avère que cette approche est très pratique car elle nous permet, par exemple, d'interdire la vente ou de clôturer de force des positions en un clic après que certaines conditions générales pouvant être décrites dans une classe de base sont remplies.
Dans certains cas, une stratégie dispose de données générales pour les ventes et les achats qui doivent être recalculées à la survenue d'un événement, par exemple l'arrivée d'un nouveau bar. Dans ce cas, il est possible pour une stratégie d'abonner ses propres méthodes de traitement aux événements. Il n'est pas possible d'ouvrir des positions dans ces méthodes, mais il est possible d'effectuer divers calculs.
Un autre point intéressant est la façon de gérer les positions ouvertes. La classe de base stocke une liste séparée de positions longues et courtes. Lorsqu'un nouvel événement se produit (par exemple, OnTick), la classe commence à lister toutes les positions ouvertes et propose de traiter chacune de ces positions une par une en utilisant les méthodes SupportBuy SupportSell. Ces méthodes ne peuvent fermer que la position qui leur est offerte par la classe de base à ce moment-là. Toutes les autres positions sont en lecture seule. Ainsi, la classe de base impose à ses descendants l'idée qu'ils doivent pour l'instant se concentrer sur une seule position. Lorsque j'ai testé cette idée, il s'est avéré que la logique du conseiller expert, même le plus complexe, est beaucoup plus simple. En outre, il apporte un soutien automatique à la notion de couverture, car le conseiller expert conserve des informations sur ses positions longues et courtes.Dès que vous commencez à traduire l'exécution d'une stratégie en ordres à cours limité, vous allez recevoir beaucoup de questions, d'une manière ou d'une autre :
Il faudra alors mettre en place une rétroaction entre l'"exécuteur" et l'"analyseur" et, en outre, les paramètres de ce mouvement non idéal devront être intégrés au modèle mathématique de l'analyseur.
MetaDriver: ... Pour vérifier les idées stratégiques dans le testeur, une chanson - aucun problème avec le commerce ...
Lorsque vous commencez à convertir l'exécution de la stratégie en ordres limités.