Mt4 Fin de l'assistance. - page 28
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 ne sais pas si quelqu'un l'a suggéré, mais pourquoi ne pas transférer tout ce qui est dans MT4 vers MT5, comme ça tout le monde passerait à autre chose.
George Merts:
Ils écrivent d'abord les parties et les combinent ensuite en un tout, découvrant souvent que les parties ne sont pas compatibles entre elles - ce qui, soit dit en passant, explique le désir d'"avoir accès à toutes les variables disponibles".
Non, ça ne l'est pas. Il ne s'agit pas d'avoir accès à toutes les variables possibles, mais seulement à celles dont vous avez besoin. Il s'agit généralement de variables d'entrée et de sortie de différentes fonctions.
Ajouter des limites supplémentaires ici rendra la lisibilité du code beaucoup plus difficile et augmentera les erreurs possibles lorsque quelque chose n'est pas arrivé parce qu'il s'est perdu en chemin à cause de ces limites.
Il est certainement compréhensible de vouloir récupérer la POO pour quelque chose d'utile, mais ces cas ne se situent généralement pas dans le domaine de la programmation, mais dans la sphère commerciale, par exemple pour des heures de programmation supplémentaires, la création de discussions sans fin sur l'architecture des interfaces et autres passe-temps agréables pendant le temps de travail.
Existe-t-il, en principe, un exemple de cela? Même si ce n'est pas le vôtre ? J'ai de profonds doutes. Au début des années deux-millièmes, j'ai cessé de compter le nombre de lignes de code de programme débogué et fonctionnel que j'avais écrites, car il dépassait le million - cela devenait inintéressant. Et je n'ai jamais rencontré la nécessité de créer ma propre classe, bien que la variété et l'ampleur de mes tâches aient été très diverses. J'ai dû utiliser des variables de type procédure lorsqu'il était nécessaire de paralléliser le travail de plusieurs personnes mais pas plus. Pourquoi en est-il ainsi ?
Le fait est que la POO ne peut être appliquée qu'à l'emballage du code prêt à l'emploi et qu'elle n'en empêche que l'étape de l'écriture du code. Mais si ce besoin n'existe pas, vous n'avez pas non plus besoin de la POO.
Vladimir:
Il s'avère que la POO empêche le parallélisme automatique des calculs. Aujourd'hui, il faut le considérer comme un inconvénient très sérieux, la perspective n'est pas pour la POO.
La perspective est dans des langages comme Systemverilog.
Tout va bien, à l'exception du fait que la fonction isNewBar() ne devrait pas exister du tout. C'est drôle qu'il y ait autant de danse autour d'une chose aussi triviale.
Il s'agit d'une variable, qui est simplement comparée au temps de la barre ; si tous les cas sont réussis, la variable se voit attribuer le temps de la nouvelle barre à la fin. Sinon, une seule tentative est attribuée à tous les cas.
Ajouter des limites supplémentaires ici rendra immédiatement la lisibilité du code beaucoup plus difficile et augmentera les erreurs possibles lorsque quelque chose n'est pas arrivé quelque part parce qu'il s'est perdu en chemin à cause de ces limites.
C'est tout le contraire - les limites vous permettent de ne pas penser à "pourquoi cette variable, quel rôle elle joue dans ce cas, faut-il la prendre en compte ?".
L'utilisateur n'a accès qu'à ce qu'il doit prendre en compte et qu'à ce qu'il peut modifier. Il s'agit précisément des erreurs "lorsque quelque chose est perdu en cours de route" - et elles surviennent précisément parce que trop de choses sont disponibles, et que quelque chose est "oublié en cours de route". Avec des intérêts virtuels "tronqués", cela est beaucoup plus difficile à faire.
Voici l'exemple le plus simple : obtenir un poste. Une position est soit un ordre ouvert dans MT4, soit une position ouverte dans MT5.
Si vous disposez d'un accès complet, lorsque vous sélectionnez une position, l'utilisateur doit se souvenir des variables qu'il peut lire maintenant, de celles qui ne sont pas valides pour le moment, de celles qu'il peut modifier et de celles qui ne le sont pas.
Avec l'interface, les choses sont beaucoup plus simples. Vous l'avez, et il n'a que deux fonctions : obtenir le nombre de composants, et obtenir un pointeur sur un composant constant. C'EST TOUT. Avec ces deux fonctions, vous n'avez physiquement pas accès à des "variables supplémentaires".
Andrei:
Bien sûr, je comprends le désir de tirer au moins d'une manière ou d'une autre la POO pour quelque chose d'utile, mais ces cas ne se situent généralement pas dans le domaine de la programmation, mais dans la sphère commerciale, comme des heures de programmation supplémentaires, des discussions sans fin sur l'architecture des interfaces et autres passe-temps agréables pendant les heures de bureau.
Et vous y viendrez tôt ou tard. En outre, l'encapsulation peut être réalisée selon une approche "purement procédurale". Mais c'est plus pratique dans l'approche POO, car vous obtenez toujours l'héritage et le polymorphisme "automatiquement".
Je ne sais pas si quelqu'un l'a suggéré, mais pourquoi ne pas transférer tout ce qui est dans MT4 vers MT5, comme ça tout le monde passerait à autre chose.
Le problème n'est pas seulement qu'il y a quelque chose dans 4 qui n'est pas dans 5. Et ce n'est même pas l'OOP.
5 n'a pratiquement rien donné aux traders (pas aux programmeurs, pas aux traders de logiciels - juste aux traders).
Format propre à l'histoire, interdiction de la personnalisation - mais ces deux points ont fait fuir tous ceux qui font du commerce de la géométrie. Et pas de "nombreux TFs" (sans année, lol), des échelles en pips par barre les attireront.
Une question simple. Que montre la "grille" ? En essayant de le découvrir, vous serez amené à recommander de vous lancer dans le freelancing et de commander ce que vous voulez.
Les MT sont des terminaux pour les programmeurs. C'est toute la réponse.
Le problème est que la POO ne peut s'appliquer qu'à l'emballage du code prêt à l'emploi, à un stade de l'écriture du code, elle ne fait qu'interférer. Mais s'il n'y a pas une telle nécessité, il n'y a pas de nécessité dans la POO.
Non, ça ne l'est pas. C'est juste l'inverse.
Les interfaces sont définies initialement, avant même "l'étape de l'écriture du code". Les interfaces sont, en fait, toutes les mêmes TdR pour le programmeur. Toutes les interactions dans le cadre de Freelance se déroulent exactement à l'aide d'un cahier des charges clair. Ainsi, les interfaces virtuelles sont une sorte de TOR, où la programmation commence.
Si je comprends bien, vous abordez l'essence même de la POO de manière incorrecte. Vous écrivez d'abord un tas de fonctions, puis vous devez les "serrer" dans la conception OOP. Mais c'est une mauvaise méthode. La bonne méthode est l'inverse - vous définissez d'abord la définition de la POO, ces ensembles d'interfaces de base entre les composants du système. Et ensuite, un par un, chaque composant est écrit en suivant ces interfaces très prédéfinies.
Oui, il arrive parfois que l'on découvre en écrivant le code que l'interface n'a pas prévu quelque chose. Et puis tu commences... "Ohhhh... Dans l'approche procédurale, j'aurais accès à tout cela et je n'aurais aucun problème à faire ce dont j'ai besoin, mais maintenant, comment puis-je avoir accès à ces variables ? Cela se produit lorsque, au stade de la conception des interfaces, quelque chose n'a pas été pris en compte. Cette situation est très désagréable : il faut soit ajouter des interfaces supplémentaires, soit modifier les interfaces existantes, ce qui est source d'erreurs. Cette situation doit bien sûr être évitée.
Voici l'exemple le plus simple : obtenir un poste. Une position est soit un ordre ouvert dans MT4, soit une position ouverte dans MT5.
Si vous disposez d'un accès complet, lors de la sélection d'une position - l'utilisateur doit se rappeler quelles variables peuvent être lues maintenant, quelles variables sont actuellement invalides, quelles variables il peut modifier, lesquelles ne le sont pas.
Avec l'interface, les choses sont beaucoup plus simples. Vous l'avez, et il n'a que deux fonctions : obtenir le nombre de composants, et obtenir un pointeur sur un composant constant. C'EST TOUT. Avec ces deux fonctions, vous ne pouvez physiquement accéder à aucune "variable supplémentaire".
C'est tout le contraire qui est vrai. Les utilisateurs ont souvent besoin de connaître les variables internes pour tester la qualité des modules, par exemple, et ce n'est pas le cas. Et des moyens spéciaux et astucieux sont inventés pour obtenir cet accès par la suite. Il n'y a donc pas d'informations redondantes en principe, et ceux qui n'en ont pas besoin peuvent simplement ne pas les utiliser.
C'est exactement le contraire. Les utilisateurs ont souvent besoin de connaître les variables internes afin de tester les modules de qualité, par exemple, et ce n'est pas le cas. Et ils trouvent des moyens spéciaux et astucieux pour obtenir cet accès par la suite. Ainsi, il n'y a pas d'informations inutiles, et ceux qui n'en ont pas besoin ne les utilisent tout simplement pas.
Si vous avez besoin d'un "accès rusé pour l'obtenir", cela indique une conception incorrecte du système.
Par exemple, si nous écrivons un générateur de signaux d'entrée, nous ne devons pas avoir accès aux informations concernant, par exemple, la gestion de l'argent.
Bien sûr, pendant le débogage, il peut y avoir une situation, par exemple, quand il n'y a pas eu d'entrée - nous devrions immédiatement éliminer la situation, quand cela s'est produit parce que la gestion de l'argent a interdit l'opération (disons, il n'y a pas assez de marge). Et comment le savez-vous à partir du générateur d'entrées ? Vous n'avez pas - vous n'avez pas accès. Mais dans ce cas - il suffit de s'assurer que le générateur a défini un signal d'entrée, et qu'il a fonctionné correctement. Il n'y a pas eu d'entrée - pour une autre raison, qui se situe en dehors du générateur d'entrée. Trouver la raison dans ce cas est vraiment plus difficile que si nous avons accès à toutes les variables de la gestion de l'argent directement. Mais il est beaucoup plus dangereux que, dans le cadre d'une opération normale et de routine, nous, qui y avons accès, " nous mettions au mauvais endroit ".
Si un accès difficile est nécessaire, cela indique une mauvaise conception du système.
Le développement est avant tout un processus naturel de l'esprit.
Dans ce processus, les idées se forment librement et même spontanément.
Suivre une POO rend difficile la transformation libre du code.
Dans le processus naturel de développement, le code lui-même se réduit et s'universalise progressivement.
Dans le processus naturel, les fonctions ne se désagrègent pas mais au contraire se développent et s'unissent en de grands blocs.
Les grands blocs permettent de résoudre un large éventail de tâches.
La POO empêche ces blocs de se former, laissant le code fragmenté.
La POO crée des accès compliqués, ce qui augmente régulièrement le nombre de références aux variables.
Les avantages de la granularité sont contrebalancés par la difficulté de réaliser un mécanisme cohérent.
Le principal inconvénient : la POO nous oblige à suivre la méthode consistant à diviser le code en un certain nombre de fonctions.
Il est plus facile pour un humain d'accepter un code fragmenté, mais la fragmentation est contre-indiquée pour tout mécanisme.