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
Peut-être que ce n'est pas une approche rationnelle de charger tous les ordres ouverts avec tous leurs paramètres dans un tableau.
Peut-être, si j'ai besoin de deux paramètres profit et stop loss dans mon code, il est trop coûteux d'exécuter la boucle deux fois.
C'est un code universel et nous pouvons supprimer les choses inutiles pour accélérer le processus final...
Simplifier
C'est pour ça que je ne supporte pas les OOP. Il est impossible de comprendre quoi que ce soit. Il n'y a pas de commentaire. Que faut-il faire à la fin ?
Pourquoi ne pas commencer à l'apprendre ?
C'est pour ça que je déteste les OOP. Il est impossible de comprendre quoi que ce soit. Aucun commentaire. Que faut-il faire à la fin ?
C'est ça le problème : vous ne comprenez pas, mais vous avez une structure de tableau avec tous les ordres et facile à appeler n'importe où. Et vous n'exécutez la boucle lourde qu'une seule fois...
Pourquoi ne pas commencer à l'apprendre ?
Remplit le tableau avec les valeurs des fonctions dans la boucle. La question est de savoir pourquoi vous avez besoin d'un shell de classe. Vous pouvez le faire avec une fonction.
Moins il y a d'appels de fonctions, plus le code est rapide.
Remplir le tableau avec les valeurs des fonctions dans la boucle. La question est de savoir pourquoi vous avez besoin d'un shell de classe. Vous pouvez également le faire avec une fonction.
La structure est très pratique - pas besoin d'empiler des tableaux et de les redimensionner individuellement. Cet exemple ne montre pas les avantages de la POO, mais simplement que chacun le fait de la manière dont il est personnellement à l'aise.
C'est ça le problème : vous ne comprenez pas, mais vous avez une structure de tableau avec toutes les commandes et facile à appeler n'importe où. En même temps, vous n'exécutez la boucle lourde qu'une seule fois...
Messieurs les argumentateurs, disons-le ainsi, si vous ne comprenez pas la POO, ne savez pas, alors discutons non pas de la programmation procédurale contre la POO, mais de la programmation procédurale avec des pointeurs vers des fonctions contre la programmation procédurale sans pointeurs vers des fonctions.
Non, votre exemple est très bon.
Il ne s'agit pas de programmation procédurale.
Il existe un critère de qualité des programmes bien plus important : la clarté du code.
La solution que vous avez donnée est affreuse : il n'est pas du tout clair QUELLE fonction est appelée de manière significative. J'écrirais un interrupteur normal et un commentaire pour chaque appel. C'est le bon code.
De votre exemple, je conclus que la POO est une chose nuisible.
Moins il y a d'appels de fonctions, plus le code est rapide.