Mt4 Fin de l'assistance. - 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
Vladimir:
Peut-être pour organiser l'interface avec l'utilisateur ? C'est là que de nombreuses variations sur la POO sont inventées, une bibliothèque de composants visuels dans Delphi. Ainsi, les conseillers experts et les scripts sont conçus pour remplacer les humains sur l'ordinateur, cette interface contredit directement leur objectif, elle n'est pas nécessaire. C'est-à-dire qu'il est dans le chemin. Tout comme les éléments inutiles dans un canif. Ou un cloueur sur l'extrémité du manche en acier d'un marteau universel - non seulement il raye, mais il déplace aussi le centre de gravité du percuteur vers le manche.
Je ne suis pas d'accord avec vous sur ce point particulier.
Une interface graphique peut être nécessaire pour les algotraders qui comprennent qu'un EA entièrement automatisé est, de loin, beaucoup moins efficace qu'un EA semi-automatisé. La combinaison du trading automatisé et du trading manuel peut être plus professionnelle et plus rentable du point de vue du trading. Lorsque les gens s'en rendront compte, leurs robots auront certainement besoin d'une interface.
1. graph_id peut être lu par une personne russophone plus rapidement que m_chart_id.
2. S'il y a des centaines de variables dans un programme, le russe apporte un soutien indispensable.
Tout cela peut être testé dans une expérience.
La vitesse de lecture et de compréhension du code dans la langue maternelle sera toujours plus rapide et la mémorisation sera meilleure.
Il vous suffit de vous familiariser avec les règles de dénomination des variables en russe. Au lieu de "variable_to_store_general_profit_position, juste : general_profit.
S'il y a des centaines de variables dans un programme, la plupart d'entre elles peuvent probablement être combinées par des structures. N'oubliez pas non plus d'utiliser des fonctions.
De nombreuses variables n'ont aucun sens, car elles sont des compteurs, des stockages temporaires de données intermédiaires, et sont utilisées derrière un tas de parenthèses. Et le meilleur de tous, derrière toutes les parenthèses, nous pouvons à nouveau utiliser les mêmes variables, mais à nouveau entre parenthèses {....}.
Ou écrire initialement en OOP.
Il me semble que l'essence de son rejet de la POO réside dans ceci. Je peux me tromper bien sûr, mais je ressens généralement les gens.
À mon avis, le problème de la plupart des non-OBO est une résistance interne à la "limitation des droits légaux".
Un programmeur de la vieille école est habitué à avoir un accès complet à toutes les données, à tous les blocs, à toutes les entités du programme, à tout moment. Et l'approche OOP implique le contraire - la limitation maximale des droits, lorsque vous - avez accès à une très petite partie des données et des actions du programme.
Si je me souviens bien, je n'ai pas beaucoup aimé. Aux premiers jours de Windows, je me souviens avoir été fortement dégoûté par l'accès protégé à la mémoire - je ne peux pas accéder à l'adresse que je veux, et si elle se trouve dans le noyau du système ? Je voudrais qu'il soit lu à partir d'un programme ou qu'il soit modifié du tout au tout ! J'ai même programmé un contrôleur d'accès direct à la mémoire, qui envoyait des données à la "zone autorisée" depuis la "zone interdite", contournant ainsi les restrictions du système.
Mais, avec le temps, j'ai vraiment apprécié toutes ces restrictions. Les accès "inutiles" peuvent toujours se transformer en erreurs. Il est donc très judicieux de confier le travail de contrôle d'accès - au compilateur. Larestriction d'accès s'avère ici "infaillible", et non "une atteinte à vos droits". Si vous avez besoin d'un accès que vous n'avez pas, cela signifie simplement que vous avez mal conçu le système - vous auriez dû le prévoir si vous en aviez besoin.
Et maintenant - au contraire, je limite toujours l'accès autant que possible. A tout moment, il ne devrait y avoir accès qu'aux entités qui sont nécessaires. Toutes les autres entités doivent être inaccessibles. Cela vous protège contre les erreurs d'accès à des endroits qui ne devraient pas l'être, et vous habitue également à une certaine séquence de développement du système, où chaque opération est effectuée à un seul endroit, et où aucun autre endroit n'est affecté.
Par exemple, je déteste les inludes sous forme de bibliothèques, juste parce que je ne sais pas ce qu'ils y mettent et comment cela peut m'aider, c'est plus facile d'écrire une douzaine de fonctions supplémentaires
similaire à ce que j'ai l'habitude de faire avec Re-Tag Konow.
Et pourquoi ?
Une seule et même fonction est requise à plusieurs endroits - pourquoi copier des fonctions quand on peut tout avoir dans les bibliothèques, et ne pas encombrer le code principal de blocs inutiles ?
Et pourquoi ?
Une seule et même fonction est requise à plusieurs endroits - pourquoi copier des fonctions quand on peut tout avoir dans des bibliothèques et ne pas encombrer le code principal de blocs inutiles ?
Tu es bon pour trouver des arguments, Nikolaï).
Grand-mère, elle aussi, peut tout assimiler sans problème. Inconsciemment, elle ne veut pas qu'une babiole entraîne son esprit tranquille dans un cycle d'informations inutiles. A juste titre).
Peter, il s'avère que vous êtes une grand-mère.
Bonjour
Je pourrais avoir de l'aide ici. J'ai une question pour les développeurs de MT4. Où peut-on l'exprimer ? Si c'est sur ce forum, alors dans quel fil ? Ou ailleurs ? Si vous le savez, dites-le moi.
Je ne suis pas d'accord avec vous sur ce point particulier.
Une interface graphique peut être nécessaire pour les algotraders qui se rendent compte qu'un EA entièrement automatisé est, de loin, beaucoup moins efficace qu'un EA semi-automatisé. La combinaison du trading automatisé et du trading manuel peut être plus professionnelle et plus rentable du point de vue du trading. Lorsque les gens s'en rendront compte, leurs robots auront certainement besoin d'une interface.
Vous soutenez pleinement la personne qui dit que mql ne devrait avoir que des fonctions d'accès au serveur, et tout le reste par des béquilles devrait être programmé par des outils de développement tiers. Ne déviez pas de la ligne du parti. Soyez cohérent - videz tous vos développements sur mql et faites un pont - en studio par exemple - ou partout où vous allez écrire vos toiles... Puis faites un rapport sur votre prochaine victoire sur l'usine.
Par exemple, je déteste les inludes sous forme de bibliothèques, juste parce que je ne sais pas ce qu'ils y mettent et comment cela peut m'aider, c'est plus facile d'écrire une douzaine de fonctions supplémentaires
similaire à celui de Retrog Konow.
Eh bien, la loi de la conservation de l'énergie : pourquoi décompiler la bibliothèque et la comprendre si tout fonctionne sans elle ?
P.S.
Tu as vu mon top sur les élans ?
Quand vos codes commencent à déborder de 10, 20, 30, ... 100 000 lignes, puis revenez me dire comment vous copiez vos codes dans un tel volume.
À mon avis, le problème de la plupart des non-OBO est une résistance interne à la "limitation des droits légaux".
Un programmeur de la vieille école est habitué à avoir un accès complet à n'importe quelle donnée, n'importe quel bloc, n'importe quelle entité de programme à tout moment. Et l'approche OOP implique le contraire - la limitation maximale des droits, lorsque vous - avez accès à une très petite partie des données et des actions du programme.
Si je me souviens bien, je n'ai pas beaucoup aimé. Aux premiers jours de Windows, je me souviens avoir été fortement dégoûté par l'accès protégé à la mémoire - je ne peux pas accéder à l'adresse que je veux, et si elle se trouve dans le noyau du système ? Je pourrais même vouloir le lire à partir d'un programme ou le modifier du tout au tout ! J'ai même programmé un contrôleur d'accès direct à la mémoire, qui envoyait des données à la "zone autorisée" depuis la "zone interdite", contournant ainsi les restrictions du système.
Mais, avec le temps, j'ai vraiment apprécié toutes ces restrictions. Les accès "inutiles" peuvent toujours se transformer en erreurs. Il est donc très judicieux de confier le travail de contrôle d'accès - au compilateur. Larestriction d'accès s'avère ici "infaillible", et non "une atteinte à vos droits". Si vous avez besoin d'un accès que vous n'avez pas, cela signifie simplement que vous avez mal conçu le système - vous auriez dû le prévoir si vous en aviez besoin.
Et maintenant - au contraire, je limite toujours l'accès autant que possible. À tout moment, seules les entités auxquelles il faut accéder doivent être disponibles. Tous les autres objets doivent être inaccessibles. Cela vous protège contre les erreurs d'accès à des endroits qui ne devraient pas l'être, et vous habitue également à une certaine séquence de développement du système, où chaque opération est effectuée à un seul endroit, et où aucun autre endroit n'est affecté.
Vous avez donné un bon exemple de ce que la POO peut repousser.
Dans mon cas, c'était un peu différent. Je me suis lancé avec détermination dans l'apprentissage de la POO, mais à un moment donné, j'ai cessé de voir un avantage pratique à l'utiliser. A ce jour, cela n'a pas changé. Tout cela parce que j'ai formé mon approche, qui a écarté la POO de ma pratique.
Cette affirmation, selon laquelle la limitation de l'accès est une protection nécessaire pour éviter les erreurs, est quelque chose que je ne comprends pas du tout. Si les noms des variables coïncident dans différentes parties du programme, bien sûr que oui. Mais s'il y a une mémoire globale commune pour toutes les variables globales principales dans un tableau, vous n'avez pas besoin de restrictions et il n'y aura pas de confusion.