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
Oui, ces unités ont les deux. Mais croyez-moi, ils sont compressés au maximum et polyvalents, car ils résolvent un large éventail de problèmes.
S'il n'y a pas beaucoup d'options, vous pouvez vous en sortir avec des "si" et des "swip".
Pourquoi personne n'a décidé de débattre de la "programmation procédurale avec pointeurs de fonction contre la programmation procédurale sans pointeurs de fonction" ?
S'il n'y a pas beaucoup d'options, vous pouvez vous en sortir avec des "si" et des "swip".
Реter Konow:
1. Дело в работе которую нужно провести чтобы сжать в коде решения огромного количества задач.
2. Le but est d'universaliser le code, dans lequel toute technique syntaxique et tout shell supplémentaires sont simplement destructeurs. C'est un travail difficile, mais il permet de se débarrasser de tout ce qui est superflu et d'évoluer sans cesse vers de nouveaux sommets.
1. Pourquoi faire le travail quand on peut le rendre facile et simple ? Pourquoi rendre les choses difficiles quand on peut les rendre faciles ?
2. Si vous utilisez la POO, l'universalisation n'est pas destructive, mais devient une possibilité naturelle qui n'alourdit rien.
1. Pourquoi faire le travail quand il peut être fait facilement et aisément ? Pourquoi faire quelque chose qui peut être fait facilement alors que c'est difficile ?
2. Si vous utilisez la POO, alors l'universalisation n'est pas ruineuse, mais devient une possibilité naturelle qui n'alourdit rien.
Nous pouvons poursuivre cet argument pendant longtemps. À l'aide de l'exemple d'une tâche de 100 trajets, j'ai montré mon attitude vis-à-vis de cette méthode de solution. Je crois que les tâches stupides ne doivent pas être résolues mais réparées. Si la POO aide ceux qui sont plus faibles pour soulever et résoudre des tâches correctement, qu'elle les aide. Mais pour les personnes qui optimisent les tâches avant de commencer à les résoudre, la POO peut tout simplement ne pas être nécessaire.
Nous pourrions poursuivre cet argument à l'infini. À l'aide de l'exemple d'une tâche de 100 trajets, j'ai montré mon attitude vis-à-vis de cette méthode de solution. Je crois que les tâches stupides ne doivent pas être résolues mais réparées. Si la POO aide ceux qui sont plus faibles pour soulever et résoudre des tâches correctement, qu'elle les aide. Mais pour les personnes qui optimisent les tâches avant de commencer à les résoudre, la POO peut tout simplement ne pas être nécessaire.
Vous n'avez pas beaucoup codé (probablement), la POO est comme une bouffée d'air.
La plupart des gens ne codent pas par intérêt ou pour s'épanouir, c'est leur travail, et c'est le résultat qui compte.
Ce n'est pas aussi pratique, mais en termes de rapidité, vous pouvez vous en sortir avec les pointeurs seuls.
Et la commodité est un concept relatif.
Dmitry, il est évident que l'utilisation de la POO réduit un peu les performances. Mais ce sont des fractions de pourcent.
Mais comment la POO augmente les performances d'un programmeur !
Voici un petit exemple tiré d'un de mes projets, il est découpé pour la perception, mais en réalité il y a beaucoup d'autres choses prises en compte.
Par exemple, prenons .NET, car toutes les API sont constituées de classes.
J'aime beaucoup le paradigme .NET. D'ailleurs, il existe un excellent terminal cAlgo, que vous pouvez écrire directement dans Visual Studio en C#.
Dimitri, bien sûr que l'utilisation de la POO réduit un peu les performances. Mais ce sont des fractions de pourcent.
Si le nombre de variantes est faible, cela le ralentira, mais s'il y a trop de variantes, ce sera un avantage.
Le plus important, c'est que le nombre de variantes dans la POO n'affecte pas les performances. Et dans la programmation procédurale, il y a un plafond au-dessus de votre tête.
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 actuel(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 des subtilités dont je ne me souviens pas. 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 a pris tout son sens lorsque les comptes couverts ont été introduits. Les experts n'ont pas changé du tout.
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 opinion est que si vous vous souvenez de tout votre code à la lettre, et que vous pouvez facilement dire pourquoi telle ou telle ligne de votre code a été écrite il y a un an - alors c'est vrai, tous ces perfectionnements 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 permet d'isoler les blocs les uns des autres, de limiter l'ensemble des entités disponibles à tout moment à un endroit particulier du programme.
Eh bien, vous avez fait un gâchis...
1. 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 - nous pouvons même tout mettre dans une énorme fonction.
La question est celle de la commodité et de l'efficacité du soutien.
2. Dans MT - l'endroit le plus approprié pour la POO est le système de commande. Personnellement, j'ai des interfaces virtuelles "positions" 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 (couverte ou compensée).
3. 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, seul un nouveau type d'ordre sera ajouté, et il supportera également cette interface.
Le système s'est avéré très raisonnable, lorsque les comptes de couverture ont été introduits. Les experts n'ont pas du tout changé depuis.
4. 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 ?
Je pense que si vous vous souvenez de tout votre code à la lettre, et que vous pouvez facilement dire pourquoi telle ou telle ligne a été écrite il y a un an - alors tous ces perfectionnements 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 à un moment donné à un endroit particulier du programme.
1. 1. Je suis tout à fait d'accord. La seule différence réside dans l'efficacité à résoudre les tâches d'une manière ou d'une autre.
2. Je n'ai pas vraiment travaillé avec le système de commande et je ne vois pas de problèmes techniques dans sa construction. Peut-être qu'il y en a, mais nous avons besoin d'une tâche concrète et alors il sera clair à quel point je peux la résoudre efficacement sans la POO.
3. De mon point de vue, l'exemple de code donné est tout simplement affreux du point de vue de la lisibilité. Il n'est pas étonnant que tant de commentaires soient nécessaires et que vous en oubliiez le contenu. Désolé, mais c'est ma première impression subjective. C'est juste effrayant.
Voici un exemple de lisibilité de mon code - la fonction qui définit la couleur de l'élément d'un contrôle :
Comme vous pouvez le constater, les commentaires sont presque inutiles ici. Tout mon code est écrit dans ce style. Je le connais donc parfaitement et je m'en souviens quelle que soit sa taille.
A mon avis, il y a un défaut 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 avéré très raisonnable" (comment peut-il être raisonnable dans 270 Ko de code ? !), cela signifie que l'auteur a une compréhension approximative du fonctionnement de son système. Et ce sont les terribles contrivances syntaxiques et les entités inutiles de la solution qui l'empêchent de la comprendre jusqu'au bout.
Pour qu'une solution soit efficace, les entités inutiles doivent être coupées et le problème doit être perçu de manière parfaitement claire.