Frais généraux de l'OLP - page 4
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
Mon expérience montre que vous en avez besoin.
J'ai suivi cette voie il y a environ cinq ans, à l'époque sur MT4. (Non pas parce que je ne connaissais pas la POO, mais parce que j'étais trop paresseux pour me préoccuper des interfaces et de l'héritage, d'autant plus qu'à l'époque MT4 et MT5 étaient sensiblement différents en termes d'implémentation de MQL). Cela m'a conduit à comprendre son erreur. Ce n'est pas une "sagesse", mais une limitation raisonnable, une sorte de "foolproof". Si vous vous souvenez toujours de ce dont chacune des centaines de variables est responsable, vous n'avez pas besoin d'encapsulation. Je ne m'en souviens pas, et je préfère avoir le moins possible d'entités disponibles dans chaque bloc d'un programme.
Dès que MQL4 est apparu OOP - j'ai commencé à traduire tous mes développements en une forme unique basée sur les interfaces.
Je n'ai toujours pas réussi à trouver quelque chose de plus pratique que le système d'ordre MQL4. Si vous avez un exemple, montrez-le-moi.
Toutes les API de trading que j'ai vues semblent monstrueuses par rapport à MQL4. Ils sont également maladroits.
Je n'ai jamais réussi à trouver quelque chose de plus pratique qu'un système de commande MQL4. Si vous avez un exemple, montrez-le-moi.
Toutes les API de trading que j'ai vues semblent monstrueuses par rapport à MQL4. Et en plus, ils sont maladroits.
A quoi bon, chaque paramètre doit être dessiné dans une fonction séparée. Il serait plus logique de recevoir la structure avec tous les paramètres par demande, comme pour les ticks.
Je n'ai jamais été capable de trouver quelque chose de plus pratique qu'un système de commande MQL4. Si vous avez un exemple, montrez-le-moi.
Toutes les API de trading que j'ai vues semblent monstrueuses par rapport à MQL4. Et en plus, ils sont maladroits.
Qu'est-ce que tu veux dire ?
L'essence même des ordres ? Oui, je suis d'accord, c'est très pratique.
Mais la simple application de la POO à ce système est, à mon avis, ce qui donne la plus grande "victoire". Disons que j'ai la même interface - elle donne à la fois la position MT4 constituée d'ordres et la position MT5 constituée de positions MT5, et ce indépendamment des conditions de couverture ou de compensation.
À mon avis, il est beaucoup plus logique et compréhensible d'avoir une liste d'objets d'ordres (ou de positions MT5) obtenue via la fonction Select() et de s'adresser aux propriétés des ordres, plutôt qu'à l'"état de l'environnement" (obtenu via la même fonction), que l'on aborde via des fonctions.
Le plus intéressant est que si nous devons suivre plusieurs ordres à la fois - dans ce cas, l'approche procédurale conduit inévitablement à une approche "pseudo-objet" - nous devons créer un tableau d'informations sur les ordres qui doivent être mis à jour lors de l'entrée dans OnTick() et travailler avec les données de l'ordre par des index dans le tableau, de la même manière qu'avec les pointeurs OOP vers les objets de l'ordre.
En outre, l'approche OOP nous donnerait un avantage lorsque nous travaillons simultanément avec des ordres historiques et actifs, puisque l'interface de l'ordre historique est le successeur de l'ordre actif. Et l'approche procédurale signifie que les commandes historiques et actives sont traitées par des fonctions différentes, ce qui est beaucoup moins pratique.
Ce qui est bien, c'est que chaque paramètre doit être tiré par une fonction distincte. Il serait logique, comme pour les ticks, d'obtenir la structure avec tous les paramètres sur demande.
Les entrées Order.TakeProfit et OrderTakeProfit() sont les mêmes. Le premier n'a que la possibilité de stocker l'objet, et le second - la pertinence. Le besoin de stockage est très rarement satisfait, et pas en TS. Et là, il n'y a aucun problème pour créer la structure.
Moi-même je me suis demandé pourquoi les développeurs n'ont pas fait le retour de la structure de la commande, et laissé chaque champ séparément à travers une fonction (pour l'historique aussi un ticket est nécessaire à chaque fois).
En général, je ne vois rien de vraiment mauvais avec MQL4-API (il se peut qu'elle ne fonctionne pas seulement dans MT4/5).
Que voulez-vous dire ?
L'essence même des opérations de commande ? Oui, je suis d'accord, très pratique.
Mais la simple application de la POO à ce système est, à mon avis, ce qui donne la plus grande "victoire". Disons que j'ai la même interface - elle donne à la fois la position MT4 constituée d'ordres et la position MT5 constituée de positions MT5, et ce indépendamment du fait qu'elle soit couverte ou compensée.
Tu as ta propre enveloppe, l'autre a la sienne. La question était de savoir s'il était possible de créer une enveloppe plus pratique que MQL4.
C'est beaucoup plus logique et compréhensible à mon avis, lorsque nous avons une liste d'objets d'ordre (ou de positions MT5) obtenus à l'aide de la fonction Select() et que nous nous adressons aux propriétés de l'ordre plutôt qu'à"l'état de l'environnement" (obtenu à l'aide de la même fonction) que nous abordons par le biais de fonctions.
Le plus intéressant est que si nous avons besoin de suivre plusieurs ordres à la fois - dans ce cas, l'approche procédurale conduit inévitablement à une approche "pseudo-objet" - nous devons créer un tableau d'informations sur les ordres qui doivent être mis à jour lors de l'entrée dans OnTick() et traiter les données des ordres par des index dans le tableau de la même manière que nous traitons les pointeurs OOP vers les objets d'ordre.
J'en ai parlé dans le billet précédent.
En outre, l'approche OOP nous donnerait un avantage lorsque nous travaillons avec des ordres historiques et actifs simultanément - puisque l'interface de l'ordre historique est héritière de l'ordre actif. La majorité des fonctions sont communes. Et l'approche procédurale nous permet de traiter les ordres historiques et actifs à l'aide de fonctions différentes, ce qui est beaucoup moins pratique.
Eh bien, dans MQL4, l'historique est géré par les mêmes fonctions (OrdersHistoryTotal ne compte pas).
Il serait bon de disposer d'un exemple de code où la propre API de commerce est clairement meilleure que la MQL4-API. J'utilise moi-même la POO presque partout. Et pour certaines tâches spécifiques, je fais des emballages commerciaux. Cependant, ils ne sont pas universels, bien que très pratiques à utiliser pour certaines tâches particulières. Cependant, je souhaite toujours comparer les API de négociation universelles.
Je me suis moi-même demandé pourquoi les développeurs n'ont pas fait du retour de la commande une structure, mais laissé chaque champ individuellement à travers une fonction (un ticket est également requis à chaque fois pour l'historique).
Alexey Volchanskiy:
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
Dans MT5, il y avait des structures, mais les retours se faisaient toujours par le biais de fonctions.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Frais généraux pour OOP
fxsaber, 2017.07.07 08:08
La question était différente, est-il possible de créer un wrapper plus pratique que MQL4 ?
Dans MT5, il y avait des structures, mais le retour se faisait de toute façon via des fonctions.
Ils ont peut-être décidé de ne pas rompre la tradition, mais ils auraient dû le faire.
Je comprends que les données soient téléchargées depuis le serveur de la société de courtage, mais elles sont locales, elles sont prises instantanément, vous pourriez remplir la structure immédiatement.
Ils ont probablement décidé de ne pas rompre la tradition, bien qu'ils auraient dû...
Je comprendrais que les données soient téléchargées du serveur DC, mais elles sont locales, elles sont prises instantanément, vous pourriez remplir la structure immédiatement.
Oui, pendant le SELECT, nous ne remplissons qu'une instance d'une structure cachée, dont les champs ne sont accessibles qu'au moyen de fonctions const(read-only).
Il s'agit probablement de la seule décision discutable du noyau de l'API de négociation. Sinon, je ne sais même pas de quoi me plaindre.
Oui, lorsque SELECT est utilisé, il remplit une instance d'une structure cachée dont les champs ne sont accessibles que par des fonctions const(read-only).