Qu'est-ce que le code OOP peut faire que le code procédural ne peut pas faire ? - page 2
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
La programmation d'interfaces graphiques est ce que j'ai fait la plupart du temps en tant que programmeur. Il n'est pas possible de coder une interface graphique complète qui doit communiquer dans plusieurs directions par "if then else". Vous auriez besoin de tant d'instructions que le code deviendrait illisible et finalement beaucoup trop lent, ce qui aurait pour conséquence de ne pas atteindre l'objectif. Fait.
Je ne vais pas construire une interface graphique en langage procédural pour prouver que vous avez tort. Mais je pourrais sans aucun doute.
D'ailleurs, il est également facile de coder un code illisible et beaucoup plus lent en POO, et comme vous le savez, la bibliothèque standard de Metaquotes en est une bonne preuve.
...
Étant donné qu'un processeur ne connaît rien à la POO, vous pouvez - bien sûr - tout coder sans utiliser de pointeurs et de tableaux complexes. Mais c'est absurde. Je pourrais aussi engager 10000 personnes qui dessinent le contenu de mon écran sur un film en temps quasi réel et le diffusent séquentiellement par un projecteur de lumière sur le mur. Est-ce là aussi un objectif à atteindre ?
Êtes-vous d'accord pour dire que le système d'exploitation Windows offre une bonne interface graphique ? Pour autant que je sache, il est écrit en C. Un langage procédural, pas OOP.
Vous avez tort Dirk si vous pensez qu'un programme complexe ne peut être construit qu'avec la POO. Vous devriez plutôt expliquer pourquoi il est préférable de le coder en POO.
Euh, allez ;) Pas vraiment ;) Si quelque chose de natif pouvait faire le travail d'une manière bizarre, alors ce sont les pointeurs, mais il y a des restrictions dans MQL. Si c'était le cas ... le code deviendrait absurde.
Je doute fortement que la POO soit une façon plus courte de coder.
Êtes-vous d'accord pour dire que le système d'exploitation Windows offre une bonne interface graphique ? Pour autant que je sache, il est écrit en C. Un langage procédural, pas une programmation orientée objet.
Vous avez tort Dirk si vous pensez qu'un programme complexe ne peut être construit qu'en POO. Vous devriez plutôt expliquer pourquoi il est préférable de le coder en POO.
J'ai codé des interfaces graphiques en Assembler, entièrement. Mais en Assembleur je peux travailler avec des pointeurs, en C je peux travailler avec des pointeurs et bien sûr la base de Windows n'est pas la POO, mais nous parlons de MQL qui ne supporte pas les pointeurs void de manière native et à cause de cela, vous ne serez pas capable de coder des interfaces graphiques complexes avec juste if then else, au moins pas avec un résultat qui peut être utilisé sans grand manque de performance.
Et cette réponse inclut déjà la question, pourquoi c'est mieux avec la POO - où "mieux" est toujours le mauvais adjectif. La méthode POO implémente l'utilisation de tels pointeurs mais sans vous forcer à vous en occuper. En interne, la POO est réalisée avec des tableaux multidimensionnels pour les pointeurs de fonctions et de variables. Essayer de coder ce genre de choses revient à réinventer une roue qui ne roulera jamais aussi bien que celle que vous avez déjà devant vous.
J'ai codé des interfaces graphiques en Assembler, entièrement. Mais en Assembler je peux travailler avec des pointeurs, en C je peux travailler avec des pointeurs et bien sûr la base de Windows n'est pas la POO, mais nous parlons de MQL qui ne supporte pas les pointeurs void de manière native et à cause de cela, vous ne serez pas capable de coder des GUI complexes avec juste if then else, au moins pas avec un résultat qui peut être utilisé sans grand manque de performance.
Et cette réponse inclut déjà la question, pourquoi c'est mieux avec la POO - où "mieux" est toujours le mauvais adjectif. La méthode POO implémente l'utilisation de tels pointeurs mais sans vous forcer à vous en occuper. En interne, la POO est réalisée avec des tableaux multidimensionnels pour les pointeurs de fonctions et de variables. Essayer de coder ce genre de choses revient à réinventer une roue qui ne roulera jamais aussi bien que celle que vous avez déjà devant vous.
Ce n'est que ma préférence personnelle due à ma petite ( !) expérience !
1) Je n'aime pas Java, par exemple, car je cherchais 99% du temps une fonction sans savoir quel était son nom, si elle existait ou non et si je devais la coder moi-même de toute façon...
2) Je n'aime pas le C++ parce que je dois écrire plus que je ne le ferais pour écrire un langage de type script comme mq4 ou même Perl.
3) Je n'aime pas le C++ parce que comprendre le code de quelqu'un d'autre me fait sauter d'un fichier à l'autre où je ne trouve que des fonctions de 2,3 lignes, ce qui rend vraiment difficile de trouver ce que et comment le s.th. est calculé. Bien sûr, il y a des explications comme "calculer l'arrêt" mais la procédure de calcul est également divisée en plusieurs fonctions dans différents fichiers.
4) Je n'ai absolument aucun problème avec les enum et les tableaux de variables d'enum. Je n'ai pas besoin de coder des objets réels imaginés. Les interfaces graphiques pourraient être un problème différent car elles sont composées de beaucoup d'autres choses qui pourraient être codées en tant qu'objets pour pouvoir les réutiliser facilement. Mais de combien d'objets différents un EA a-t-il besoin ? Un pour les positions ? S'il y avait beaucoup d'objets différents (GUI), cela pourrait aider - mais je ne les vois pas ici.
5) Enfin, MQ5 ne peut toujours pas exécuter son backtest sur les ticks des clients:( <Edited by moderator as off-topic : this has nothing to do with mql5 but with MT5>.
je respecte vraiment quelqu'un qui code assemble, vous devez avoir une bonne connaissance de la façon dont le matériel lui-même fonctionne, tout simplement étonnant, difficile personne n'utilise aujourd'hui
Je ne le code plus, mais dans le passé, je l'utilisais principalement. Sur les puces Intel 80x86, c'était la seule chance d'obtenir un réel avantage en termes de performances visuelles. Et bien sûr, c'est une connaissance de base que je ne veux pas manquer du tout, même si je n'en ai plus besoin en détail, mais vous savez toujours ce qui se passe avec votre code à la fin et vous savez comment utiliser cela comme un avantage en termes de vitesse d'exécution.
Oui, le "bon" vieux temps ;) ... Mais aussi fou, il n'y avait même pas de variables, pas de vraies fonctions, pas de si alors autre chose, juste des registres, des piles, des interruptions et des adresses mémoire. De la merde :)
La POO est un outil pour diviser le code en petites parties réutilisables. Mais la meilleure partie est constituée par les modèles. Cette fonctionnalité vous permet de simplifier le code. Le meilleur exemple est la classe de tableau. En Java, vous devez créer une classe pour le type. En C++ et Mql5, vous pouvez les avoir dans une seule classe, ce qui réduit le code redondant et contourne certains problèmes lorsque vous mélangez primitives et objets.
PS : A propos d'ASM, c'est de la vieille école. Je l'ai utilisé avant les premiers compilateurs en mode protection et j'ai pu dépasser les limitations. Les segments de 64K avec des sélecteurs étaient le cauchemar des codeurs de l'époque. Chaque fois que vous écriviez au mauvais endroit, vous deviez redémarrer l'ordinateur :)