Demande non valide - je viens de commencer et je n'arrive pas à comprendre... - page 6
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
J'en ai écrit un pour moi, mais pour quatre.
Ainsi, avez-vous personnellement écrit une bibliothèque universelle, détachée de la logique commerciale de l'EA et pouvant être utilisée dans n'importe quelle EA ?
Je n'y crois pas non plus. Bien sûr, le code du gestionnaire de réponse du serveur était présent, mais il était intégré à la logique de l'entreprise et non à une bibliothèque universelle.
Vous avez donc personnellement écrit une bibliothèque universelle, détachée de la logique métier de l'EA et qui peut être utilisée dans n'importe quelle EA ?
Je n'y crois pas non plus. Bien sûr, le code du gestionnaire de réponse du serveur était présent, mais il était intégré à la logique de l'entreprise et non à une bibliothèque universelle.
Oui, je peux le prouver. Pour un prix, bien sûr.
Je veux dire qu'il n'y a pas non plus de bibliothèque pour MT4.
Ce n'était pas si difficile à prouver.
C'est-à-dire qu'il n'y a pas non plus de bibliothèque pour MT4.
Ce n'était pas si difficile à prouver.
Renat, j'ai le sentiment que l'utilisation de la bibliothèque standard tombe sous le refrain : "POO ou pas POO".
Sinon, je ne comprends pas pourquoi les gens ont la ferme conviction qu'un wrapper OOP, qui simplifie les opérations commerciales, ne devrait pas être utilisé.
Certains prétendent qu'un wrapper s'occupe de toute la logique, gère les erreurs, répète les requêtes, etc. Et en même temps, son utilisation est supposée dangereuse et il y a une erreur dans chaque ligne...
C'est-à-dire qu'il est là.
Vous ne l'avez pas. Toutes les erreurs sont gérées par la logique métier.
Vous utilisez la propriété de synchronisation dans MT4, ce qui simplifie le traitement dans une certaine mesure, mais vos méthodes ne garantissent pas 100 % de tous les cas. Probablement 95% et c'est purement votre bible sur laquelle est basé tout le processus de trading.
Mais MT5 est beaucoup plus complexe en termes de gestion des codes de retour et d'asynchronisme.
Vous demandez l'impossible à une enveloppe. La bibliothèque standard n'est pas une logique d'entreprise. Il s'agit d'une enveloppe "par-dessus" les fonctions du terminal. Un emballage au-dessus de la farce d'une barre chocolatée.
Il s'agit d'une interface conviviale qui prend en charge une partie de la routine. Reprenant le même type de code. On ne mange pas un emballage en papier en se plaignant qu'il n'est pas comestible. :)
Mais le wrapper ne peut rien garantir, puisque c'est vous qui vous portez garant. Votre logique d'entreprise. :)
Tout comme la fonction d'impression ne peut pas garantir l'espace disque libre et les erreurs de journalisation. Vous devez utiliser d'autres fonctions pour la gestion des erreurs et elles sont spécifiques à chaque cas.
-Alexey-, parlons de défauts spécifiques et vous exprimez des défauts spécifiques que vous aimeriez corriger.Si vous le souhaitez, vous pouvez passer en revue chaque code de retour et examiner les principales situations possibles.
Répondez aux questions :
- pourquoi est-ce que je traînerais toutes ces 61 méthodes derrière moi ? Est-ce rationnel ?
La question va dans le plan de savoir si vous avez besoin ou non de la programmation OOP. Je ne peux pas y répondre sans ambiguïté.
Dans ma pratique, j'utilise la POO pour les modèles de haut niveau.
Bien sûr, j'en utilise beaucoup dans ma base, juste dans les fonctions.
De même, lorsque j'utilise une classe OOP, elle contient beaucoup de choses inutiles pour une tâche particulière, comme la fonctionnalité de la bibliothèque de dessin kanvas. Il y a des lignes, des carrés et du texte. Mais il n'y a pas à discuter de la question de savoir si cette classe doit avoir un carré ou non. C'est juste là. Pour une tâche particulière.
Il y a trop de problèmes qu'ils essaient de résoudre dans une seule classe.
vous vous trompez. Ils ne résolvent aucun problème. Ils se sont enroulés autour de RUTINA. Est-ce difficile à comprendre ?
Par conséquent, la gestion des erreurs doit être pour toutes les tâches à résoudre.
Il ne peut pas être là. Puisque la bible ne résout aucun problème. Il simplifie la RUTINE, c'est tout. Il ne peut pas faire plus, et il n'a pas besoin d'être compliqué.
La solution est assez simple : diviser une classe encombrante en plusieurs classes plus petites, en fonction des problèmes à résoudre :
Dans ce cas, je ne ferai intervenir que les classes qui correspondent à ma stratégie et rien de superflu. Et il sera beaucoup plus facile de mettre en œuvre la gestion des erreurs qu'aujourd'hui.
Eh bien, ce n'est pas une routine enveloppante. Il résout déjà les problèmes avec la logique spécifique de VOTRE expert.
Vous ne pouvez pas prévoir la gestion des erreurs même dans une seule fonction - ouverture ou fermeture. On trouve toujours 1001 cas, lorsque les erreurs prévues ne conviennent pas et qu'il faut faire autre chose.
Si vous connaissez une fonction universelle pour toutes les situations, veuillez la montrer. Je ne peux même pas imaginer comment il est possible de prévoir à l'avance toutes les possibilités de traitement des erreurs, sans connaître la logique d'une EA particulière.
Même si je fais une telle fonction, cela contredit toutes vos paroles les plus hautes - "vous avez encore fait trop de bruit".
Et si vous appliquez votre méthode d'écriture du code par le biais de macros avec direction (ORDER_TYPE_BUY / ORDER_TYPE_SELL), alors les classes seront assez compactes.
Où est tout cela ?
Mais les macros n'ont pas non plus de gestion d'erreur. Elles sont gérées par la logique métier d'un conseiller expert particulier dans une erreur particulière. Il n'est pas si difficile de comprendre qu'il n'y a pas de situations universelles.
Si Renat apprenait à écouter les suggestions du forum et essayait de saisir le sens de ces suggestions, MT5 serait bien plus avancé qu'il ne l'est aujourd'hui à ce stade de développement.
Renat ne cesse de le répéter - nous sommes sur un forum technique. Nous ne pouvons pas parler ici de choses abstraites.
Alors, s'il vous plaît, donnez-nous des détails. Réfléchissons aux termes de référence, aux fonctions commerciales dont il a besoin et aux erreurs possibles et à la manière de les traiter. ok ?
Répondez aux questions :
- si j'ai juste besoin de placer un ordre au marché, ou un ordre en attente, pourquoi devrais-je traîner toutes ces 61 méthodes derrière moi ? Est-ce rationnel ?
- Si j'ai une position ouverte et que j'ai juste besoin de fixer des stops, pourquoi devrais-je faire glisser toute cette fonctionnalité avec 61 méthodes ? Est-ce rationnel ?
- Si j'ai une position ouverte avec des stops qui seront déclenchés lorsque le prix atteindra leur niveau, pourquoi devrais-je faire glisser toutes ces 61 méthodes ? Est-ce rationnel ?
Personne ne vous l'interdit :
Quel est l'intérêt de "séparer les opérations pour les métiers en différentes classes".
C'est la même chose que si vous aviez des EA différents pour l'ouverture, la fermeture et la modification. Cela semble possible, mais personne ne le fait (sauf rares exceptions, tâches spéciales).
Et j'aime beaucoup la phrase "si j'ai juste besoin de placer un ordre au marché ou un ordre en attente, pourquoi devrais-je traîner toutes ces 61 méthodes avec moi ? Est-ce que c'est rationnel ?"
Eh bien, il y aura environ 100kb de surcharge de mémoire par conseiller expert. Bon sang...
Au fait, voici un sondage Utilisez-vous la bibliothèque standard pour les opérations commerciales ?
Franchement, je n'aurais pas dû sortir mon post.