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
Et si vous n'utilisez pas de classes, vous vous fatiguez à écrire constamment quelque chose comme SymbolInfoDouble(_Symbol,MODE_BID). Cela danse à chaque fois - à la fois les parenthèses et le soulignement, et vous ne savez pas si vous devez appuyer sur la touche de verrouillage des majuscules (et ensuite, sans regarder ailleurs, taper toute une chaîne en majuscules et la retaper) ou garder la manette enfoncée. C'est du moins là que la POO est utile. Si l'on fait au moins des classes pour toutes ces fonctions, alors oui - elles sont énormes. Si vous l'écrivez pour vous-même, ce n'est pas un problème. En ce qui concerne le travail avec les commandes, il n'y a pas tant de fonctions fréquemment utilisées, nous pouvons simplement mettre quelques fonctions dans une bibliothèque. Mais en général, une approche idéale n'a pas encore été trouvée.
Voici ma vision de la classe qui peut ouvrir/fermer/définir le stop loss et plus tard afficher lestatut de l'ordre.
et notez l'utilisation sur un symbole - spécialement une classe statique à utiliser
dans l'ensemble, tout fonctionne comme prévu.... mais je n'aime pas ça, comme je l'ai écrit plus haut c'est encombrant et superflu
Et si vous n'utilisez pas de classes, vous en aurez assez d'écrire constamment quelque chose comme SymbolInfoDouble(_Symbol,SYMBOL_BID). Cela danse à chaque fois...
Vous pourriez faire des enveloppes plus pratiques et plus concises pour ces fonctions, tout en les gardant dans le style procédural. Surtout en tenant compte du fait que dans les constructions récentes, ils ont finalement ajouté l'espace de noms, tout est génial. Avant, vous deviez les mettre en œuvre comme des méthodes statiques, mais maintenant tout est beaucoup plus facile :
Vous pouvez créer des enveloppes plus pratiques et plus concises pour ces fonctions, tout en restant dans le style procédural. Surtout depuis qu'ils ont enfin ajouté l'espace de noms dans les dernières versions, c'est génial. Avant, vous deviez les implémenter comme des méthodes statiques, mais maintenant tout est beaucoup plus simple :
Est-il important de rester dans les limites ? S'il est important de rester dans les limites, vous pouvez également écrire des fonctions.
Eh bien, pas beaucoup, je dirais qu'il y a beaucoup d'actions pour définir un ordre, voici ma vision d'une classe qui sait comment ouvrir/fermer/définir le stoploss/et ensuite sortir le statut de l'ordre.
et notez l'utilisation sur un symbole - spécialement une classe statique à utiliser
dans l'ensemble, tout fonctionne comme prévu.... mais je n'aime pas ça, comme je l'ai écrit plus haut c'est encombrant et superflu
Oui, voici une autre question qui revient sans cesse et qui n'a pas de réponse univoque. Lorsque vous devez hériter de votre propre classe, qu'est-ce qui est le mieux à faire, en hériter ou écrire une nouvelle version étendue de votre classe.
Il est possible de faire des enveloppes plus pratiques et plus concises pour ces fonctions, tout en restant dans le style procédural. D'autant plus qu'ils ont finalement ajouté l'espace de noms dans les dernières versions, c'est génial. Avant, vous deviez les implémenter comme des méthodes statiques, maintenant les choses sont beaucoup plus simples :
Vous n'avez pas de notation succincte, s'il n'y a pas de contrôles, il est plus facile d'écrire tel quel :
et notez que pour être utilisé sur un seul caractère - spécifiquement une classe statique utilisée
Votre entrée n'est pas laconique, s'il n'y a pas de contrôles, il est plus facile d'écrire tel quel :
Il y a beaucoup de fonctions comme SymbolInfoDouble. En les regroupant en classes, vous n'avez pas à vous soucier de l'unicité des noms.
J'ai le circuit suivant où je n'ai eu aucun problème.
vous n'avez pas une entrée concise, s'il n'y a pas de contrôles, il est plus facile d'écrire tel quel :
Qu'est-ce qui vous empêche de passer le nom du symbole au constructeur, rendant ainsi la classe flexible et polyvalente ? Ne considérez-vous pas fondamentalement la possibilité de faire du trading de portefeuille ?
Ce qui gêne, c'est que la plupart des EA sont écrites en un seul caractère, et que passer un symbole serait une action inutile (et épuisante)) dans la plupart des cas. Une autre possibilité est de faire en sorte que le symbole du graphique soit automatiquement sélectionné par défaut, et si nécessaire, vous pouvez remplacer le symbole pendant un certain temps. Mais une fois encore, la question se pose de savoir ce qui est le mieux : utiliser une instance de la classe et remplacer le symbole si nécessaire, ou créer une instance distincte pour chaque symbole.