Qu'est-ce que le code OOP peut faire que le code procédural ne peut pas faire ?
OOP est conçu pour travailler et penser comme les êtres naturels, imaginons que nous voulons développer un jeu de guerre où nous avons des véhicules avec de nombreux types, des soldats avec de nombreuses compétences et des armes avec de nombreuses spécifications.
Le développement de ce type de jeu sans la POO sera une douleur pour le développeur de garder la trace de tous ces types d'objets et de gérer les structures de données et la mémoire, et aussi de simuler les caractéristiques de la POO comme l'héritage sera difficile (bien que cela puisse être fait), la POO a rendu plus facile de penser et de développer aussi plus facile d'écrire, lire et déboguer le code.
Parfois, le fait d'avoir une POO plus que nécessaire rendra la compréhension et la lecture du code moins aisées (mon point de vue personnel), ce que je n'aime pas.
En fait, je ne pense pas qu'il puisse exister une tâche qui ne puisse pas être refactorisée d'un code procédural en POO ou vice versa. La différence réside dans la maintenabilité et la lisibilité du code. Par exemple, dans le code procédural, vous pouvez faire référence à des données globales et/ou locales (variables). En plus de celles-ci, la POO ajoute une portée supplémentaire - les variables internes de l'objet (état). Il est très facile et naturel de les utiliser dans la POO, et l'implémentation procédurale de la même logique nécessiterait une sorte de contournement avec du code et des structures de données supplémentaires. En d'autres termes, la POO est juste une façon plus courte et plus agréable de coder.
Comment voulez-vous construire une solution de rechange pour les fonctions virtuelles surchargées, y compris l'arbre d'héritage - qui est la partie la plus importante de la POO ? Vous semblez parler de structures, pas de POO.
OOP est conçu pour travailler et penser comme les êtres naturels, imaginons que nous voulions développer un jeu de guerre où nous avons des véhicules de plusieurs types, des soldats avec plusieurs compétences et des armes avec plusieurs spécifications.
le développement de ce type de jeu sans la POO sera une douleur pour le développeur de garder la trace de tous ces types d'objets et de gérer les structures de données et la mémoire bien, et aussi de simuler les caractéristiques de la POO comme l'héritage sera difficile (bien que cela puisse être fait), la POO a rendu plus facile de penser et de développer aussi plus facile d'écrire, lire et déboguer le code.
Parfois, avoir une POO plus que nécessaire rendra la compréhension et la lecture du code peu aisées (mon point de vue personnel), ce que je n'aime pas.
Forum sur le trading, les systèmes de trading automatisés et le test des stratégies de trading.
Qu'est-ce que le code POO peut faire que le code procédural ne peut pas ?
Alain Verleyen, 2016.05.22 14:03
J'ouvre ce sujet dans l'espoir de recueillir des informations utiles sur les avantages de la programmation orientée objet par rapport à la programmation procédurale.
De plus, ce sujet est indépendant du langage puisque mql4 et mql5 offrent le même langage OOP (sauf quelques nouvelles fonctionnalités avancées non encore disponibles dans mql4 pour le moment).
Je ne veux pas d'une "guerre" entre les partisans et les opposants de la POO, donc ce sujet sera étroitement modéré, ne perdez pas votre temps et le mien s'il vous plaît.
Veuillez également fournir des exemples et du code pour illustrer votre point de vue, pas de théorie élevée ou de concepts abstraits.
EDIT : bien que ce sujet soit indépendant du langage, nous parlons toujours de commerce et de mql4/mql5, donc pas de "jeux de guerre" ou d'exemples "pommes et oranges" s'il vous plaît.
Je suis un grand fan de la POO - je ne peux même pas imaginer que je reviendrais à la MQL procédurale. Il est plus facile de rendre les programmes plus complexes. Quoi qu'il en soit... le problème avec MQL est qu'un nouvel utilisateur a du mal à démarrer ici.
- Les méthodes d'événements intégrées ne sont pas OO. Vous devez vous y accrocher, ce qui nécessite la déclaration des objets d'écoute au niveau de la racine. L'un des principes de base de la POO est compromis par cette conception.
- il manque des paquets de code "système" avec des modèles communs. Cela empêche de créer des paquets compatibles entre utilisateurs, et un codeur POO sérieux a besoin de beaucoup de temps pour créer ses propres paquets. Les préfixes de noms de classes (noms de paquets) non supportés ne sont qu'un problème mineur - lorsque vous ne pouvez pas réutiliser le code externe de toute façon.
Je ne recommanderais donc pas de commencer à apprendre la POO directement dans le MQL. Le codeur doit savoir ce dont il a besoin pour que cela fonctionne.
L'instruction "if...then...else..." devrait faire l'affaire.
Euh, allez ;) Pas vraiment ;) Si quelque chose de natif peut 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. Et si vous acceptez le code absurde comme une réponse à la question de ce fil, alors il est obsolète du tout ;) Êtes-vous d'accord que l'absurdité est une bonne frontière ? Allez, dis oui, juste une fois et juste pour mon ego ;)
Désolé mais non je ne dirai pas oui...un code atteint son but ou non, s'il fonctionne en accord avec les spécifications, il n'y a rien d'absurde.
La question est "qu'est-ce que la POO peut faire que le procédural ne peut pas faire" ? Stanislav disait que la POO peut faire la même chose que le procédural mais d'une manière "plus courte et plus agréable". J'ai tendance à être d'accord (sauf sur l'idée de raccourcissement mais ce n'est pas si important).
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 tellement d'instructions que le code deviendrait illisible et, à la fin, beaucoup trop lent, ce qui signifierait.. : Objectif non atteint, car je ne veux pas être obligé de boire une tasse de café après chaque clic jusqu'à ce que je voie le résultat.
Étant donné qu'un CPU 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 ?
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
J'ouvre ce sujet dans l'espoir de recueillir des informations utiles sur les avantages de la programmation orientée objet par rapport à la programmation procédurale.
De plus, ce sujet est indépendant du langage puisque mql4 et mql5 offrent le même langage POO (à l'exception de quelques nouvelles fonctionnalités avancées qui ne sont pas encore disponibles dans mql4 pour le moment).
Je ne veux pas d'une "guerre" entre les partisans et les opposants de la POO, donc ce sujet sera étroitement modéré, ne perdez pas votre temps et le mien s'il vous plaît.
Veuillez également fournir des exemples et du code pour illustrer votre point de vue, pas de théorie élevée ou de concepts abstraits.
EDIT : bien que ce sujet soit indépendant du langage, nous parlons toujours de commerce et de mql4/mql5, donc pas de "jeux de guerre" ou d'exemples "pommes et oranges" s'il vous plaît.