Programmation OOP vs programmation procédurale - page 24
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
1. Il existe un critère. Le principal critère est la rapidité d'exécution.
La visibilité du code n'est pas le bon critère.
Tout le monde doit passer de toute urgence à un système plus simple ..... mais rapide ..... il est vrai que ce qui est rapide, c'est la bonne organisation de l'ensemble du projet ou la rapidité des fonctions individuelles.
Tout le monde se déplace d'urgence vers l'embouteillage..... mais rapide.... mais ce qui est rapide, c'est la bonne organisation de l'ensemble du projet ou la rapidité des fonctions individuelles.
Tout le monde se déplace d'urgence vers l'embouteillage..... mais rapide.... ce qui est vraiment rapide, c'est la bonne organisation de l'ensemble du projet ou la rapidité des fonctions individuelles.
Non, continuez à coder à travers le ***.
Eh bien, je ne suis pas d'accord.
La clarté du code est une chose très importante, car un code clair est beaucoup plus facile à maintenir et à modifier.
C'est vrai - j'ai écrit une fonction nue, et je l'ai ensuite "obscurcie", rendue invisible et incompréhensible. C'était une décision forcée. Dans ce cas, il était plus important pour moi de rendre la classe entière transparente. J'ai sacrifié la clarté d'une fonction tout à fait triviale. Bien sûr, j'aurais pu mettre le corps de cette fonction dans le fichier .mq5, mais je pense que les interfaces ne devraient pas être divisées en deux fichiers et devraient être complètement décrites dans le fichier d'en-tête .mqh.
La vitesse est également un élément à prendre en compte, mais je ne pense pas qu'il faille rechercher la "vitesse à tout prix". Il doit y avoir une suffisance raisonnable.
Probablement le même point 3 pour vous aussi
Je programme depuis longtemps. Depuis la sortie de MT3.
Depuis, je me sens plus à l'aise pour écrire en style procédural sur mql4. Je n'ai pas d'EAs sur 1001 lignes. De plus, je n'ai que quelques fonctions stockées dans des bibliothèques.
Et dans MQL5, j'utilise la bibliothèque standard. C'est une chose commode.
Mais il faut optimiser les performances pour éviter d'appeler des fonctions de plus en plus lourdes. Récemment, j'ai modifié un EA de Mql4 à MQL5. J'ai utilisé la bibliothèque présentée ici. Il m'a fallu une demi-journée pour comprendre toutes les fonctions et cela a fonctionné, mais l'optimisation était très lente. J'ai réduit l'indicateur à 2 barres et tout s'est mis à voler.
La conclusion est simple. Tout le monde peut écrire dans n'importe quel style. MQL n'est pas vraiment un langage qui nécessite une optimisation du code afin de gagner quelques millisecondes grâce à la programmation procédurale. Les tâches logiques sont plus importantes. La façon dont ils sont mis en œuvre n'a pratiquement aucun effet sur la vitesse.
...
La conclusion est simple. Tout le monde peut écrire dans n'importe quel style. MQL n'est pas vraiment un langage, qui nécessite une optimisation du code, afin de pouvoir gagner quelques millisecondes en utilisant la programmation procédurale. Les tâches logiques sont plus importantes. La manière dont ils sont mis en œuvre n'a pratiquement aucun effet sur la vitesse.
Ainsi, on laisse discrètement entendre que c'est la programmation procédurale qui fournit les hautes performances. Depuis trois jours, je vous montre un problème qui ne peut être résolu que par la POO, sans ralentissements inutiles.
La POO nous permet de cribler des ensembles de variables du reste du code, ce qui nous permet d'éviter de passer des paramètres aux méthodes lorsque nous effectuons des calculs à l'intérieur d'une classe, ce qui est un facteur important de rapidité. Même si vous le faites dans un style procédural, vous devrez créer un nombre énorme de variables globales, et par conséquent, la lisibilité du code est incroyablement faible.
Il a été si gentiment déçu que c'est la programmation procédurale qui fournit les hautes performances. Depuis trois jours maintenant, je montre ici un problème qui ne peut être résolu que par la POO sans freins inutiles.
La POO nous permet de cribler des ensembles de variables du reste du code, ce qui nous permet d'éviter de passer des paramètres aux méthodes lorsque nous effectuons des calculs à l'intérieur d'une classe, ce qui est un facteur important de rapidité. Même si vous le faites dans un style procédural, vous devrez créer un nombre énorme de variables globales, ce qui rend la lisibilité du code incroyablement faible.
Le gain du style procédural est négligeable, car le code est lancé à chaque tick dans les Expert Advisors. Et il peut y avoir des centaines ou même des dizaines de millisecondes entre les tics. Je n'ai jamais pris la peine d'utiliser des indicateurs. Je n'ai pas trouvé de réel profit à tirer des indicateurs.
Cependant, il est probablement plus pratique d'utiliser la POO pour les grands projets. Pour ma part, je préfère utiliser des structures, si je dois sauver quelque chose.
Dans ce cas, l'accès aux données est plus clairement organisé et le menu déroulant est très pratique à utiliser. Si vous remplacez les structures par des tableaux, il y a souvent confusion et le nombre de tableaux augmente.
Dans le post précédent, je mettais exactement l'accent sur l'appel de fonctions lourdes. Par exemple, des sortes de boucles qui n'ont pas besoin d'être appelées à chaque tic. Et vous n'avez pas non plus à le faire sur chaque nouvelle barre.
C'est là que le véritable gain de performance peut être augmenté.
Oui. C'est un débat amusant : pelleteuse contre pelle.
Je suppose que si tu veux planter un arbre, une pelle est préférable. Mais si vous voulez creuser un trou, la pelleteuse est probablement meilleure.
Oui. C'est un débat amusant : pelleteuse contre pelle.
Je suppose que si tu veux planter un arbre, une pelle est préférable. Mais si vous voulez creuser un trou, la pelleteuse est probablement meilleure.
Oui. C'est un débat amusant : pelleteuse contre pelle.
Je suppose que si tu veux planter un arbre, une pelle est préférable. Mais si vous voulez creuser un trou, la pelleteuse est probablement meilleure.