Record sur le marché - page 31
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
Probablement parce que je ne travaille pas pour une entreprise. Et je trouve plus facile d'utiliser la programmation procédurale plutôt que la POO.
Il y a eu beaucoup de débats à ce sujet, bien sûr.
La semaine dernière, j'ai modifié l'algorithme d'estimation de la qualité des transactions pour ma ligue TS. Et je suis très heureux que tout soit basé sur des interfaces virtuelles.
Le fait est qu'auparavant, le prélèvement maximal n'était estimé que par solde. Et je voulais l'estimer par équité. Mais pour ce faire, lors de l'analyse de l'historique - pour chaque transaction, il est nécessaire de demander la série chronologique, et de voir quel était le drawdown maximal de la transaction, sur la base des prix de l'époque.
Maintenant, rappelez-vous que mon code est portable, ce qui signifie que sur la base de la même interface - MT4 et MT5 fonctionnent tous les deux. En conséquence, pour chaque plate-forme - appelle la classe appropriée avec ses propres fonctions, qui sont sensiblement différentes. Ainsi, pendant que je modifiais le code - probablement une douzaine de fois, je me suis retrouvé dans une situation où je n'étais pas en mesure d'accéder directement aux données requises - les interfaces ne le permettaient pas. Et à chaque fois, je me suis assuré que j'avais raison, que les interfaces m'avaient limité - si j'avais "joué" directement avec ces données, cela aurait provoqué des erreurs dans d'autres parties du programme. Les données dont j'avais besoin, j'ai dû y accéder d'une manière différente, par des requêtes supplémentaires, ce qui m'a permis d'être sûr qu'aucune autre partie n'était affectée.
En résumé : une fois de plus, je suis convaincu que le principe "à chaque endroit, l'utilisateur ne doit avoir accès qu'aux structures dont il a besoin sur le moment et à aucune autre" est absolument correct. Vous ne pouvez pas permettre à l'utilisateur d'avoir toujours accès à tout - cela entraînerait des erreurs de modification.
Mais d'un autre côté, les personnes habituées à un style procédural se limitent simplement dans ces cas-là à se rappeler quelles données peuvent être modifiées à partir d'un endroit donné et lesquelles ne le peuvent pas.
Eh bien, la semaine dernière, j'ai apporté quelques modifications à l'algorithme d'évaluation de la qualité des transactions pour mon TS de la Ligue. Et je suis très heureux que tout soit basé sur des interfaces virtuelles.
Le fait est qu'auparavant, le prélèvement maximal n'était estimé que par solde. Et je voulais l'estimer par équité. Mais pour ce faire, lors de l'analyse de l'historique - pour chaque transaction, il est nécessaire de demander la série chronologique, et de voir quel était le drawdown maximal de la transaction, sur la base des prix de l'époque.
Maintenant, rappelez-vous que mon code est portable, ce qui signifie que sur la base de la même interface - MT4 et MT5 fonctionnent tous les deux. En conséquence, pour chaque plate-forme - appelle la classe appropriée avec ses propres fonctions, qui sont sensiblement différentes. Ainsi, pendant que je modifiais le code - probablement une douzaine de fois, je me suis retrouvé dans une situation où je n'étais pas en mesure d'accéder directement aux données requises - les interfaces ne le permettaient pas. Et à chaque fois, je me suis assuré que j'avais raison, que les interfaces m'avaient limité - si j'avais "joué" directement avec ces données, cela aurait provoqué des erreurs dans d'autres parties du programme. Les données dont j'avais besoin, j'ai dû y accéder d'une manière différente, par des requêtes supplémentaires, ce qui m'a permis d'être sûr qu'aucune autre partie n'était affectée.
En résumé : une fois de plus, je suis convaincu que le principe "à chaque endroit, l'utilisateur ne doit avoir accès qu'aux structures dont il a besoin sur le moment et à aucune autre" est absolument correct. Vous ne devez pas laisser l'utilisateur avoir toujours accès à tout ce dont il a besoin - cela pourrait provoquer des erreurs de modification.
Mais, d'un autre côté, les personnes habituées au style procédural se limitent dans de tels cas à se rappeler quelles données peuvent et ne peuvent pas être modifiées à partir d'un endroit donné.
Eh bien, c'est la concurrence. On ne peut rien y faire. N'abandonnez pas. Continuez à avancer et à gagner. Sinon, vous serez laissé pour compte.
Oubliez l'OLP. Si cette question vous dérange, je peux vous dire qu'en programmation, vous ne devez utiliser que ce dont vous pouvez vous passer. Si vous pouvez utiliser un style procédural, faites-le.
Mon principe :"Si vous pouvez vous passer de quelque chose pour résoudre une tâche, vous devez absolument vous en passer".
Le chien a-t-il besoin d'une cinquième patte ? :)
Exactement.
C'est le genre de compétition dont vous avez besoin.
Vous seriez surpris, mais je souffre toujours de la programmation procédurale.
Je me suis mis à Pascal quand j'avais 14 ans et je ne peux pas me changer. Et j'ai "appris les cours" il y a longtemps, mais je ne peux pas changer d'avis...
Probablement parce que je ne travaille pas pour une entreprise. Et je trouve plus facile d'utiliser la programmation procédurale plutôt que la POO.
Les principes de la POO ne diffèrent pas beaucoup de la programmation procédurale, d'autant plus que dans les programmes MQL, les tâches sont hautement spécialisées et il est souvent inutile de développer la structure interne d'une classe. Plus de 90 % des exemples utilisant des classes dans Codobase ne sont rien de plus que de la programmation procédurale "enveloppée dans une classe", car les tâches qui sont résolues par une classe ne sont exécutées qu'une seule fois et l'héritage et le polymorphisme ne sont pas utilisés (parce qu'il n'y en a pas besoin).
Et les problèmes sérieux, où il n'y a pas de solution sans POO - c'est un graphique. Ce problème a déjà été résolu et il est en libre accès et il faut juste savoir l'utiliser ou le modifier (comme l'héritage).
Ils l'ont déjà fait et il est disponible gratuitement, il s'agit juste de savoir comment l'utiliser (graphiques en MQL) ou comment en hériter (comment utiliser l'héritage).
ZZZY : c'est ce que je ne dirai pas au sujet de l'utilisabilité en termes d'ALGLIB - elle devrait certainement être "enveloppée" dans une classe normale !
Igor Makanu:
...
Et les tâches sérieuses pour lesquelles vous ne pouvez pas vous passer de la POO sont les graphiques...
Très controversé.))
Très controversé.))
Les principes de la POO ne diffèrent pas beaucoup de la programmation procédurale, surtout dans les programmes MQL, les tâches sont hautement spécialisées et il est souvent inutile de développer la structure interne d'une classe. Plus de 90 % des exemples utilisant des classes dans Codobase ne sont rien de plus que de la programmation procédurale "enveloppée dans une classe", car les tâches qui sont résolues par une classe ne sont exécutées qu'une seule fois et l'héritage et le polymorphisme ne sont pas utilisés (parce qu'il n'y en a pas besoin).
Et les problèmes sérieux, où il n'y a pas de solution sans POO - c'est un graphique. Ce problème a déjà été résolu et il est en libre accès et il faut juste savoir l'utiliser ou le modifier (comme l'héritage).
Ils l'ont déjà fait et il est disponible gratuitement, il s'agit juste de savoir comment l'utiliser (graphiques en MQL) ou comment en hériter (comment utiliser l'héritage).
ZZZY : c'est ce que je ne dirai pas au sujet de l'utilisabilité en termes d'ALGLIB - elle devrait certainement être "enveloppée" dans une classe normale !
Ça dépend pour quoi faire.
Pour la facilité d'utilisation par d'autres utilisateurs ?
Possiblement, oui.
Pour que les utilisateurs n'aient pas envie de "faire des bêtises" et de causer du tort.
J'utilise 5 fonctions de dessin pour mes graphiques (texte, bouton, case à cocher, champ, arrière-plan) !)
Tout est clair pour moi. Les autres n'ont pas besoin de le voir.
Exactement.
C'est le genre de compétition dont nous avons besoin.
Je rêve qu'une telle concurrence se développe sur notre marché. Seul le marché a besoin d'être nettoyé.
Pour parfaire la baignade, il faut d'abord nettoyer la piscine, puis la remplir d'eau. En bref, il faut des conditions favorables.
Si la piscine est sale, personne ne voudra participer à la compétition. :)Eh bien, la semaine dernière, j'ai apporté quelques modifications à l'algorithme d'évaluation de la qualité des transactions pour ma ligue TS. Et je suis très heureux que tout soit basé sur des interfaces virtuelles.
Le fait est qu'auparavant, le prélèvement maximal n'était estimé que par solde. Et je voulais l'estimer par équité. Mais pour ce faire, lors de l'analyse de l'historique - pour chaque transaction, il est nécessaire de demander la série chronologique, et de voir quel était le drawdown maximal de la transaction, sur la base des prix de l'époque.
Maintenant, rappelez-vous que mon code est portable, ce qui signifie que sur la base de la même interface - MT4 et MT5 fonctionnent tous les deux. En conséquence, pour chaque plate-forme - appelle la classe appropriée avec ses propres fonctions, qui sont sensiblement différentes. Ainsi, pendant que je modifiais le code - probablement une douzaine de fois, je me suis retrouvé dans une situation où je n'étais pas en mesure d'accéder directement aux données requises - les interfaces ne le permettaient pas. Et chaque fois, je me suis assuré que j'avais raison, que les interfaces m'avaient limité - si j'avais "puisé" dans ces données directement - cela aurait entraîné des erreurs dans d'autres parties du programme. Les données dont j'avais besoin, j'ai dû y accéder d'une manière différente, par des requêtes supplémentaires, ce qui m'a permis d'être sûr qu'aucune autre partie n'était affectée.
En résumé : une fois de plus, je suis convaincu que le principe "à chaque endroit, l'utilisateur ne doit avoir accès qu'aux structures dont il a besoin sur le moment et à aucune autre" est absolument correct. Vous ne devez pas laisser l'utilisateur avoir toujours accès à tout ce dont il a besoin - cela peut provoquer des erreurs de modification.
Mais, d'un autre côté, les personnes habituées à un style procédural se limitent simplement dans ces cas-là, en se rappelant quelles données peuvent être modifiées à partir d'un endroit donné et lesquelles ne le peuvent pas.
Avec tout le respect que je vous dois, vos arguments sont ceux d'un très vieil homme qui explique et prouve la nécessité du bâton sur lequel il s'appuie. Sans elle, je vais sûrement tomber. C'est vrai. Mais pas pour tout le monde.
Très controversé.))
Peut-être, mais je suis aussi un "dinosaure de la fin des années 90". J'ai vu Turbo Pascal et les rudiments du graphisme sous la forme de bibliothèques qui, quelle que soit la manière dont vous les présentez, vous donnent toujours Norton Commander )))).
Mais avec l'avènement (et mon passage) à Delphi, comme on dit, c'est là que la vie a commencé..... Je n'arrive pas à imaginer comment faire des fenêtres actives, des cases à cocher, etc. sans la POO, je suppose en théorie, mais je ne vois même pas comment on peut le faire sans la POO, comme on dit on s'habitue à une bonne chose !
Avec tout le respect que je vous dois, vos arguments sont ceux d'un très vieil homme qui explique et prouve la nécessité du bâton sur lequel il s'appuie. Sans ça, je suis sûr de tomber. C'est vrai. Mais pas pour tout le monde.
Vous, si je me souviens bien, vous vous souvenez parfaitement de tout ce qui se trouve dans votre énorme ensemble de données. Moi, par contre, je ne me souvenais pas de telles choses, même quand j'étais jeune. Maintenant, quand je suis un vieil homme, je ne peux certainement pas me souvenir de tout ce que je voulais dire quand j'ai écrit un certain bloc. Ce "bâton" m'aide vraiment beaucoup. Mais, je suis d'accord que si quelqu'un est capable de conserver tout ce qui est nécessaire dans sa mémoire, il peut s'en passer.
Néanmoins, j'ai déjà cité plusieurs fois le code respecté de fxsaber, alors que lui-même ne pouvait pas me dire exactement comment il fonctionne. C'est juste qu'il comporte des contrôles très délicats et non évidents qui sont effectivement difficiles à retenir. Et l'homme ne se souvient pas. Le consensus était que "ce code a été vérifié de nombreuses fois, on peut donc lui faire confiance". Mais que se passera-t-il si certains protocoles de travail changent ? Le code devient immédiatement invalide, et dans ce cas - au lieu de corriger ce qui a changé - il devra être réexaminé jusqu'à ce que l'on retrouve l'endroit qui a été modifié.
C'est à ça que servent ces "bâtons". Les produits logiciels sont aujourd'hui si compliqués qu'il est irréaliste de garder à l'esprit toutes leurs subtilités. C'est pourquoi diverses techniques sont utilisées (la POO n'est que l'une d'entre elles).