Programmation OOP vs programmation procédurale - page 11
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, il y a une faille dans votre système de résolution des problèmes. Le problème lui-même doit être parfaitement clair et précis, et donc sa solution aussi. Si la solution est nébuleuse et définie par les mots "Le système s'est montré très raisonnable" (comment peut-il être raisonnable dans 270 kb de code ? !), cela signifie que l'auteur comprend à peu près le fonctionnement de son système. Et ce sont les effrayants artifices de syntaxe et les entités superflues de la solution qui l'empêchent de la comprendre jusqu'au bout.
Le caractère raisonnable réside dans le "pouvoir prédictif" - un changement important des protocoles de travail n'a pas nécessité de modifier le code des experts responsables de la logique de leur travail. La modification du code ne s'est faite qu'à l'endroit qui manipule directement le terminal à un niveau bas.
Le code donné montre très bien comment toutes les bidouilles de la POO peuvent être remplacées par des "bidouilles fonctionnelles". C'est exactement ce que je disais plus haut - cela peut être écrit dans les deux sens.
Mais en regardant votre code, je vois que vous devez garder beaucoup plus en mémoire. Dis, dans la plupart de tes "si", je me suis "noyé" dans un moment. Ils sont corrects, mais si je devais maintenir ce code - j'insérerais avant chaque condition quelques lignes de commentaires, ce que fait cette vérification et pourquoi ces champs sont utilisés dans le tableau. Similaire au commentaire avant de déclarer l'interface CTradePositionI dans mon code. De plus, des conditions complexes me stresseraient personnellement beaucoup.
Je ferais personnellement plus d'erreurs dans votre code, et il serait plus difficile de les attraper. En d'autres termes, malgré l'exactitude et la logique d'un tel code, il me serait plus difficile de le maintenir que si je l'avais écrit dans le style OOP.
Dans le style POO, je déclarerais des interfaces de fenêtres, de parties de canevas, d'éléments, de canevas, puis j'écrirais de véritables classes de ces objets, et ensuite je donnerais des pointeurs vers ces interfaces dans les bons blocs, et je travaillerais spécifiquement avec ces entités, qui seraient nécessaires à ce moment-là - tout le reste serait indisponible à ce moment-là. Ainsi, vous ne devez pas vous souvenir de ce qui appartient à quoi et de ce qui est responsable de quoi. Lorsque vous disposez de l'interface la plus simple, composée de quelques fonctions, vous vous contentez de travailler avec elle, et le reste est inutile et indisponible pour vous. Vous n'avez pas besoin de vous souvenir de quoi que ce soit.
Eh bien, vous avez fait un gâchis...
Il est clair que toute tâche peut être résolue à la fois dans le style POO, avec l'attribution d'interfaces, la construction d'une hiérarchie d'héritage, la déclaration de fonctions virtuelles, et dans le style procédural pur - vous pouvez même tout mettre dans une énorme fonction.
La question est celle de la commodité et de l'efficacité du soutien.
Dans MT - l'endroit le plus approprié pour la POO est le système de commande. Personnellement, j'ai des interfaces virtuelles pour "position" et "composants de position". "Position" est un ensemble d'ordres dans MT4 ou un ensemble de positions dans MT5. La "composante de la position" est un ordre individuel ou une position MT5 individuelle (couverture ou compensation).
Voici le fichier d'interface proprement dit(Retag Konow, vous pouvez apprécier le nombre de commentaires par rapport à la quantité de code, et j'en ajoute périodiquement lorsque je rencontre que je ne me souviens pas de certaines subtilités. Par exemple, j'oublie régulièrement quels objets réels constituent un "composant de position". Je n'ai pas besoin de m'en souvenir - le conseiller expert travaille avec des composants selon l'interface, et ce qui se trouve derrière cette interface n'a pas d'importance en réalité. Mais, je dois y revenir pendant la modification - c'est pourquoi j'ai très souvent besoin du premier commentaire dans ce fichier) :
Le fichier de l'interface du composant commercial est le suivant (je l'ai déjà donné plus haut, mais je vais le répéter :
En fonction de ces interfaces, j'ai mis en place un système d'ordres MT4 et MT5 pour les ordres réels et historiques.
Le conseiller expert qui demande une position reçoit cette interface et ne doit pas tenir compte de la différence entre les ordres MT4 et MT5. Et si un nouveau type d'ordre est ajouté ou si l'ordre de travail avec eux est modifié - rien ne changera pour le conseiller expert, seule la nouvelle classe de type d'ordre sera ajoutée, et elle supportera également cette interface.
Le système s'est révélé très astucieux lorsque les comptes de couverture ont été introduits. Les experts - absolument aucun changement par rapport à cela.
Reg Konow, comment gérez-vous la différence entre les types d'ordres dans MT4 et MT5 ?
Si un nouveau type de compte est introduit (en plus de la couverture et de la compensation), quels changements devront être apportés, et au même endroit ?
À mon avis, vraiment, si vous vous souvenez de tout votre code à la lettre, et que vous pouvez facilement dire pourquoi telle ou telle ligne a été écrite dans votre code il y a un an - alors, vraiment, toutes ces améliorations de la POO ne sont que des gestes inutiles.
La POO est nécessaire précisément lorsque vous ne vous souvenez pas de tout lorsque vous modifiez le code - la POO vous permet d'isoler les blocs les uns des autres pour limiter l'ensemble des entités disponibles à tout moment à un endroit particulier du programme.
George, tu écris parfois une telle clinique sur les femmes, mais respecte le code )))).
Le caractère raisonnable réside dans le "pouvoir prédictif" - un changement important dans les protocoles de fonctionnement - qui n'a pas nécessité de modifier le code de l'EA responsable de la logique de leur fonctionnement. La modification du code n'a été effectuée qu'à l'endroit qui manipulait directement le terminal à un niveau inférieur.
Le code donné montre très bien comment toutes les bidouilles de la POO peuvent être remplacées par des "bidouilles fonctionnelles". C'est exactement ce que je disais plus haut - cela peut être écrit dans les deux sens.
Mais en regardant votre code, je vois que vous devez garder beaucoup plus en mémoire. Dis, dans la plupart de tes "si", je me suis "noyé" dans un moment. Ils sont corrects, mais si je devais maintenir ce code - j'insérerais avant chaque condition quelques lignes de commentaires, ce que fait cette vérification et pourquoi ces champs sont utilisés dans le tableau. Similaire au commentaire avant de déclarer l'interface CTradePositionI dans mon code. De plus, des conditions complexes me stresseraient personnellement beaucoup.
Je ferais personnellement plus d'erreurs dans votre code, et il serait plus difficile de les attraper. C'est-à-dire qu'en dépit de la justesse et de la logique d'un tel code, son support serait plus difficile pour moi que si j'avais tout écrit dans le style OOP.
Dans le style POO, je déclarerais des interfaces de fenêtres, de parties de canevas, d'éléments, de canevas, puis j'écrirais de véritables classes de ces objets, et ensuite je donnerais des pointeurs vers ces interfaces dans les bons blocs, et je travaillerais spécifiquement avec ces entités, qui seraient nécessaires à ce moment-là - tout le reste serait indisponible à ce moment-là. Ainsi, vous ne devez pas vous souvenir de ce qui appartient à quoi et de ce qui est responsable de quoi. Lorsque vous disposez de l'interface la plus simple, composée de quelques fonctions, vous vous contentez de travailler avec elle, et le reste est inutile et indisponible pour vous. Vous ne devez vous souvenir de rien du tout.
Dans mon code, le grand nombre de polices et leur imbrication est dû au comportement complexe des différentes définitions de contrôle à différents événements et dans différents états. Cependant, cette fonction couvre toutes ces variations et "sert" entièrement l'interface graphique. Lors du redécoupage d'un élément, la couleur de la pièce est déterminée par la valeur de la couleur d'origine dans le noyau et par cette fonction.
P.S. Concernant le style OOP ou procédural, alors - "A chacun son style" (c).
Georges, tu écris parfois une telle clinique sur les femmes, mais respecte le code ))))
A propos du code - je suis flatté. (Vraiment, sans blague).
Et à propos des nanas... Je ne suis pas un Casanova comme toi... Je suis celui qui se retient et ne dit pas ce que je pense... J'ai toujours eu et j'ai encore beaucoup de problèmes à cet égard, bien qu'une vie personnelle confortable ait toujours été très importante pour moi... C'est bien que parfois la chance m'ait souri, et il y a quelque chose à retenir, après tout.
A propos du code - je suis flatté. (Vraiment, sans blague).
Et à propos des femmes... Je ne suis pas un Casanova comme toi... Je suis celui qui se retient et ne dit pas ce que je pense... J'ai toujours eu et j'ai encore beaucoup de problèmes à cet égard, bien qu'une vie personnelle confortable ait toujours été très importante pour moi... C'est bien que parfois la chance m'ait souri, et il y a quelque chose à retenir, après tout.
C'est juste que nous avons des attitudes différentes envers les femmes. Je pense qu'il faut les aider. Oui, ils sont grincheux, ont leurs propres problèmes, sont inconstants dans leurs passions, etc. Il suffit de ne pas les prendre au sérieux, sinon il y aura des drames moraux.
Eh bien, vous avez fait un gâchis...
Il est clair que toute tâche peut être résolue à la fois dans le style POO, avec l'attribution d'interfaces, la construction d'une hiérarchie d'héritage, la déclaration de fonctions virtuelles, et dans le style procédural pur - vous pouvez même tout mettre dans une énorme fonction.
La question est celle de la commodité et de l'efficacité du soutien.
Nous pouvons le faire, mais l'efficacité de l'opération varie. Nous ne parlons pas ici de soutien, c'est trop relatif.
Il existe des tâches qui ne peuvent pas être résolues de manière optimale.
Nous avons juste des attitudes différentes envers les femmes. Je pense qu'il faut les aider. Oui, ils sont grincheux, ont leurs manies, sont inconstants dans leurs prédilections, etc. Il suffit de ne pas les prendre au sérieux, sinon il y aura des drames moraux.
Alexei, avez-vous fait une expérience sur le caractère infini du désir d'aide d'une femme ? Avez-vous rencontré la satisfaction de l'aide et combien de temps cela a-t-il duré ?
Je suppose que vous n'utilisez même pas de structures pour stocker des données ? Vos tableaux multidimensionnels rappellent l'ancien MQL4, où vous deviez utiliser de telles solutions par manque de structures. Mais maintenant, quel est l'intérêt ? Par exemple
vous pourriez le remplacer par
C'est plus court, plus sûr et plus rapide. Dans le premier cas, il n'y a aucun contrôle à l'étape de la compilation sur les valeurs des index des tableaux que vous lui passez. Et il faut ensuite nettoyer toutes sortes de "array out of range" en cours d'exécution - et c'est au mieux. Pire encore, lorsque l'indice est acceptable mais incorrect. C'est pourquoi une bonne pratique de programmation consiste à impliquer le compilateur autant que possible, en détectant les erreurs à l'étape de la compilation et non en les rattrapant au moment de l'exécution comme dans votre cas.
Oui, pour l'instant, vous êtes doué pour vous souvenir des valeurs à donner à tel ou tel endroit. Mais c'est probablement parce que vous êtes constamment occupé par ce projet. Essayez de faire une pause pendant, disons, six mois, et sentez la différence. Certaines personnes l'ont déjà mentionné. Ou vous pensez que nous sommes tous sclérosés ou quelque chose comme ça ? :) C'est une chose courante pour un programmeur...
La tâche consiste donc à minimiser la probabilité de se tirer une balle dans le pied. Je vous recommande vivement de créer vos propres types en utilisant les enum au lieu de l'omniprésent int. Et ils ne doivent pas nécessairement avoir des valeurs énumérées, l'essentiel est qu'il s'agisse d'un type indépendant distinct, qui sera contrôlé par le compilateur, et qui ne vous permettra pas d'échanger des arguments de fonction, etc.
J'écris uniquement et exclusivement en POO.
Dans les années 1900, je n'arrivais pas à m'y mettre - Pascal 6.0, puis Borland C++ 4.5. Mais quand je l'ai maîtrisé, je ne peux pas imaginer autre chose - c'est tellement simple et pratique maintenant.
Je suppose que vous n'utilisez même pas de structures pour stocker des données ? Vos tableaux multidimensionnels rappellent l'ancien MQL4, où vous deviez utiliser de telles solutions par manque de structures. Mais maintenant, quel est l'intérêt ? Par exemple
vous pourriez le remplacer par
C'est plus court, plus sûr et plus rapide. Dans le premier cas, il n'y a aucun contrôle à l'étape de la compilation sur les valeurs des index des tableaux que vous lui passez. Et il faut ensuite nettoyer toutes sortes de "array out of range" en cours d'exécution - et c'est au mieux. Pire encore, lorsque l'indice est acceptable mais incorrect. C'est pourquoi une bonne pratique de programmation consiste à impliquer le compilateur autant que possible, en détectant les erreurs à l'étape de la compilation et non en les rattrapant au moment de l'exécution comme dans votre cas.
Oui, pour l'instant, vous êtes doué pour vous souvenir des valeurs à donner à tel ou tel endroit. Mais c'est probablement parce que vous êtes constamment occupé par ce projet. Essayez de faire une pause pendant, disons, six mois, et sentez la différence. Certaines personnes l'ont déjà mentionné. Ou vous pensez que nous sommes tous sclérosés ou quelque chose comme ça ? :) C'est une chose courante pour un programmeur...
La tâche consiste donc à minimiser la probabilité de se tirer une balle dans le pied. Je vous recommande vivement de créer vos propres types en utilisant les enum au lieu de l'omniprésent int. Et ils n'ont pas besoin d'avoir des valeurs énumérées, l'essentiel est qu'il s'agisse d'un type indépendant distinct, qui sera contrôlé par le compilateur, et qui ne vous permettra pas d'échanger des arguments de fonction, etc.
J'ai lu vos messages sur d'autres fils et j'ai réalisé que vous êtes un grand expert en programmation. Bien sûr, je ne le suis pas et ne prétends pas l'être. Cependant, je me considère comme un spécialiste de la résolution de tâches en tant que telles. Ne pensez-vous pas que l'efficacité de la solution est la chose la plus importante ?
La surcharge de la syntaxe et la complexité des règles n'ont jamais contribué à maintenir l'efficacité de la solution. C'est la simplicité et la brièveté exprimées par la concision, l'universalité et la lisibilité des blocs de code qui ont fait la différence.
Mes règles en matière de programmation sont les suivantes : moins de code, moins de règles, moins de syntaxe et moins de commentaires, au détriment de l'utilisation du langage natif et des noms significatifs des variables et des fonctions.
Ma thèse principale est la suivante : "si vous pouvez vous passer de quelque chose dans une solution, vous devez absolument vous en passer".
Je ne pense pas du tout qu'il y ait des personnes sclérosées ici)). Il suffit de regarder les codes donnés pour comprendre pourquoi ils sont facilement oubliés. Le fait même de programmer dans une langue étrangère joue un rôle. Lorsque vous programmez dans votre propre langue, c'est absolument différent. Vous ressentez de la puissance et de la liberté au lieu de la tension et de la contrainte. Une langue étrangère demande plus d'efforts, prend plus de temps pour entrer dans le code et sort plus vite de votre tête. C'est juste un "facteur biologique".
Par conséquent, je considère (assez raisonnablement) qu'il est inefficace d'utiliser la POO en général pour résoudre mes tâches. Beaucoup de règles, de syntaxe et tout cela dans une langue étrangère. De cette façon, le talent ne peut pas vraiment se développer, ce qui signifie que le résultat sera moins bon.