PLO - page 7
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
A mon avis, vous vous trompez lourdement !
Lorsque vous aurez de gros projets (au moins plusieurs milliers de lignes de code), vous verrez que la programmation avec des classes (OOP) permet de contrôler très facilement le processus de développement et, surtout, le processus de débogage.
En outre, la POO rend les projets plus proches de la vie réelle, en fait, dans la vie réelle, nous traitons juste des instances d'objets (une maison, un arbre, un homme, une voiture, une commande, etc.), c'est-à-dire avec un ensemble de propriétés et de méthodes :)
Essayez de faire quelque chose en OOP, vous verrez que c'est plus élégant et plus clair. C'est plus facile que la programmation procédurale !
MoneyJinn:
Utilisez la programmation procédurale habituelle dans MetaTrader 5.
La POO est un développement de la programmation procédurale.
Après tout, personne ne conteste que l'on puisse se passer de fonctions. En fait, il est même plus rapide, jusqu'à un certain point. Il importe peu qu'il existe des fragments de code qui effectuent une seule et même action avec des données différentes. Il est très facile de faire une copie.
L'utilisation répétée de fonctions perd au profit de la POO. L'extension de fonctionnalité est toujours la création d'une nouvelle fonction et la refonte du code pour permettre d'appeler cette fonction en fonction de différentes conditions. Dans un programme OOP correctement écrit, une extension est une chose simple qui ne nécessite pas de refaire tout le code.
Si, en écrivant des programmes sans POO, vous n'êtes pas gêné par des problèmes d'échelle, l'abondance de données inutiles et des centaines de fonctions, le chevauchement aléatoire de variables et la nécessité de "changer à chaud" de fonctionnalité, vous n'avez pas besoin de POO.
Oui, vous ne devriez pas écrire en POO pour le plaisir de la POO, rien de bon n'en sortira. Vous ne devriez pas remplacer les fonctions par des classes. Éviter les anti-modèles
OOP est un bug, comme "Niva" ou "Lada".
Utiliser la programmation procédurale régulière dans MetaTrader 5.
Il est aussi accessible ici qu'il l'est dans MetaTrader 4.
Dommage que MetaQuotes ne le mette pas en valeur.
La POO est une évolution de la programmation procédurale.
Si, lorsque vous écrivez des programmes sans POO, vous n'avez pas de problèmes d'échelle, d'abondance de données supplémentaires et de centaines de fonctions, de variables se chevauchant accidentellement, de besoin de "remplacement à chaud" de la fonctionnalité, alors vous n'avez pas besoin de POO.
Oui, vous ne devriez pas écrire en POO pour le plaisir de la POO, rien de bon n'en sortira. Vous n'avez pas besoin de remplacer les fonctions par des classes.
Je suis d'accord à 100%.
En outre, la POO rend les projets plus proches de la vie réelle, car dans la vie réelle, nous traitons seulement des instances d'objets (maison, arbre, personne, machine, ordre, etc.), c'est-à-dire avec un ensemble de propriétés et de méthodes :)
Qu'est-ce qui est le plus proche de la réalité : une maison virtuelle, un arbre, une personne ou le fait de voir le programme dans la séquence dans laquelle il est effectivement exécuté par le processeur ?
C'est une question religieuse. Et chacun a son propre choix.
Mon post était une réponse à une question d'un topicstarter bloqué qui a fini par payer pour son aversion pour la POO,
Il s'agit également d'une réponse aux traders ordinaires qui tentent de maîtriser un produit comme MT5 ou de passer de MT4 à MT5.
Mon message était une réponse à une question d'un topicstarter bloqué qui a fini par payer le prix de son aversion pour la POO,
Une liste de contrôle pour le lanceur de sujets :
La programmation orientée objet est (lisez la phrase à l'envers) une programmation orientée objet. Ou encore, la programmation par objets.
Par objet, on entend le code du programme (généralement isolé des autres codes), qui décrit lesparamètres et le comportement d'objets réels (par exemple "machine") ou fictifs (par exemple "grail poopkin"). Chaque objet peut avoir une vie propre et mijoter dans son propre jus. Un ensemble limité de "canaux nerveux" est utilisé pour communiquer avec le monde extérieur. - comme les fonctions spéciales avec accès externe.
À mon avis, le principal avantage de la POO est que le code objet peut être débogué indépendamment des autres codes. Et ensuite, vous pouvez assembler, comme une mosaïque, des objets plus complexes. Par exemple, un objet "femme" peut inclure d'autres objets : "fuselage", "train d'atterrissage", "réservoirs", "cockpit", etc.
L'assistant MQL5 est un bon exemple de MQL OOP. Il vous permet d'assembler le conseiller expert à partir d'objets prêts à l'emploi. Et ces objets peuvent être combinés.
L'argument le plus tragique en faveur de la POO : ceux qui ont compris son essence, en deviennent accros. Il est tout simplement plus facile de programmer ; le code est plus clair et plus structuré.
...
L'argument le plus accablant en faveur de la POO : ceux qui la comprennent y deviennent accros. Il est tout simplement plus facile de programmer, le code est plus compréhensible et plus structuré.
C'est vrai, jusqu'à ce que je maîtrise OOP, il me semblait que c'était tellement nul, que ça ne valait même pas la peine de le mélanger.
Une fois que je l'ai compris, tout est devenu clair, je n'ai plus besoin d'inventer des noms uniques pour les variables,
Vous n'avez pas besoin de créer des noms uniques pour les variables, vous n'avez pas besoin de créer des noms uniques pour les compteurs i et j et vous n'avez pas besoin de chercher dans des milliers de fois du code pour trouver où cette variable n'est pas annulée. :o), et surtout, tout est sous vos yeux - lorsque vous ouvrez le programme, tout est immédiatement clair, voici l'appel de l'objet, voici l'interaction des objets, si vous voulez comprendre ce que fait l'objet, vous allez dans le code de l'objet ...
C'est vrai, jusqu'à ce que je maîtrise OOP, il me semblait que c'était un tel tas de conneries que ça ne valait même pas la peine de s'y intéresser.
Dès que je l'ai compris, je me suis débarrassé de tout, je n'ai plus besoin d'inventer des noms de variables uniques,
Vous n'avez pas besoin de créer des noms uniques pour les variables, vous n'avez pas besoin de créer des noms uniques pour les compteurs i et j et vous n'avez pas besoin de chercher dans des milliers de fois du code pour trouver où cette variable n'est pas annulée. :o), et surtout, tout est clair comme la paume de votre main, lorsque vous ouvrez le programme, tout est immédiatement compréhensible, voici l'appel de l'objet, voici l'interaction des objets, si vous voulez comprendre ce que fait l'objet, allez voir le code de l'objet
+10
Je conteste même l'affirmation selon laquelle il ne faut pas utiliser la POO pour les petits projets.
Il me semble que la POO devrait être utilisée partout où c'est possible - le code s'allonge un peu, mais sa transparence augmente de nombreuses fois.
+10
Je contesterais même la thèse selon laquelle, pour les petits projets, il n'est pas nécessaire d'utiliser la POO.
Il me semble que la POO devrait être utilisée partout où c'est possible - le code s'allonge un peu, mais sa transparence augmente de nombreuses fois.
Je suis un partisan de la POO car j'ai compris l'intérêt de programmer de bas en haut. Des interfaces d'interaction entre objets à la mise en œuvre des classes. Tous ceux qui commencent par implémenter des classes n'écrivent pas dans une POO correcte, ils écrivent des enveloppes fonctionnelles. De tels wrappers ne fournissent rien d'autre qu'un espace de noms pratique pour les variables et les fonctions. C'est l'approche habituelle des bibliothèques. Mais même ce minimum convient à certaines personnes et elles disent fièrement "j'écris en POO", ce qui est leur droit, cependant.
Il existe des programmeurs compétents et des fondateurs de courants entiers dans le logiciel moderne qui ont suffisamment d'expérience pour critiquer le paradigme de la POO. Il s'agit d'un vieux sujet et, en principe, tout a été discuté dans les moindres détails il y a longtemps, quand et où ce qui est perdu :
http://blogerator.ru/page/oop_why-objects-have-failed
Voici la réponse des partisans de la POO
http://bugtraq.ru/library/programming/objectshavenotfailed.html
Comparaison de la vitesse du C++ (petit test) Programmation orientée objet et procédurale (+ différents compilateurs)
https://www.mql5.com/ru/forum/132434/page3