Programmation OOP vs programmation procédurale - page 35
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
Attention, nous ne parlons pas de variables internes de MT, nous parlons de variables internes d'objets que vous avez isolées, empêchant la possibilité de lire leurs valeurs pendant le débogage et l'écriture du code...
C'est ce que je dis - lorsque vous déboguez un EA, n'avez-vous pas besoin des variables internes de MT ?
De même, dans ce cas, avec l'objet processeur de transaction - si vous déboguez, disons, la méthodologie de placement des ordres dans votre TS - pourquoi auriez-vous accès aux variables internes du processeur de transaction ?
Andrei est encore plus clinique que Peter ou Sansanych, vous perdez votre temps.
Les jeunes ont besoin d'être instruits.
D'ailleurs, il y a peut-être une raison rationnelle dans ce que disent mes adversaires. Si j'avais, disons, un souvenir tel que celui de Peter, je ne m'embêterais peut-être pas non plus avec l'OLP.
Il en va de même à d'autres endroits : si certaines données sont requises, ce bloc doit fournir l'interface appropriée.
C'est ce que je veux dire... Au lieu de se contenter de voir la valeur de la variable requise, il faut réfléchir à la manière d'y attacher une interface appropriée, puis de la décrocher. :)
Cela ressemble à une activité pour les masochistes de la programmation :)
Oui... il n'y a rien de mieux qu'une bite :) L'idée est d'avoir un langage de programmation adéquat, pour faciliter le débogage et l'écriture du code avec un minimum de gestes, mais ici nous avons une situation complètement opposée...
Il ne s'agit pas d'une "situation inverse". Il est vrai que la POO nécessite un travail supplémentaire. Cependant, elle est plus que compensée par la commodité du support et de la modification du système.
Là encore - pour en revenir au processeur commercial - il est écrit et utilisé dans de nombreux TS. C'est l'isolation de ses internes du TS, et le fait de ne travailler qu'à travers une interface virtuelle permet de ne pas penser aux variables qui s'y trouvent et à quoi elles sont égales. Si des erreurs sont détectées, elles se trouveront à l'intérieur du processeur et il sera nécessaire de les corriger dans une classe réelle, sans affecter les classes TS. Si l'erreur se trouve dans le TS lui-même, elle n'affectera pas les variables du processeur commercial.
L'encapsulation est en fait une technique très utile.
Oui... on ne peut s'empêcher de se demander ce qu'on a fait :) L'idée est d'avoir un langage de programmation adéquat, pour faciliter le débogage et l'écriture du code avec un minimum de gestes, mais ici nous avons une situation complètement opposée...
Le débogage est facilité précisément par la division des responsabilités dans chaque classe : chaque classe est responsable de son propre ensemble de variables. Aucune autre classe n'a le droit de changer ses valeurs. Par conséquent, la plupart des problèmes sont déjà éliminés au stade de la compilation. Et l'accès aux variables à partir de n'importe quel endroit du programme peut être comparé à une douzaine de volants sur un seul navire.
Les jeunes ont besoin d'être instruits.
En outre, il y a peut-être une base rationnelle dans ce que disent mes adversaires. Si j'avais, par exemple, un souvenir tel que celui de Peter, je ne m'embêterais pas non plus avec la POO.
1. Dans quelle mesure la rentabilité de vos conseillers a-t-elle augmenté grâce à l'utilisation des POE?
2. Dans quelle mesure la rentabilité de vos conseillers a-t-elle diminué du fait de l'utilisation des AAE ?
C'est ce que je veux dire... Au lieu de se contenter de voir la valeur de la variable requise, il faut réfléchir à la manière d'y attacher une interface appropriée, puis de la décrocher. :)
Cela ressemble à une activité pour les masochistes de la programmation :)
Vous voyez, plus haut sur le sujet, Peter vous a montré une de ses structures, pas la plus grande.
Pouvez-vous le découvrir facilement ?
C'est justement ce "masochisme" qui vous permet, premièrement, de ne pas entrer dans le code de travail et de ne pas le gâcher. Et deuxièmement, il vous permet de concevoir immédiatement la structure du système afin de pouvoir fournir les données nécessaires dans les blocs correspondants du programme.
Oui, en effet, il y a des situations où vous réalisez soudainement qu'il est presque impossible d'obtenir les données nécessaires. Ils sont cachés derrière plusieurs interfaces virtuelles. Cependant, cette situation montre clairement que le système a été mal conçu à l'origine, il ne prévoyait pas la transmission de ces données. Cette situation est en effet très désagréable. Nous devons soit construire à la hâte des "béquilles" sous la forme d'interfaces supplémentaires, soit restructurer l'ensemble du système. Enfin... Cela incite le programmeur à réfléchir plus attentivement à l'architecture du système.
Si vous aviez moins d'émotion et de réflexivité et plus de spécificité dans l'essence de la discussion - vous n'en vaudriez pas la peine. :)
Il n'y a plus de substance à cette discussion. Vous êtes fondamentalement flou et prétendez être obtus.
Si un modérateur supprime les deux dernières pages parce qu'elles ne sont pas pertinentes par rapport au sujet du fil de discussion et à la programmation en général, il est rare que je soutienne ses actions.
1. Dans quelle mesure la rentabilité de vos EA a-t-elle augmenté grâce à l'utilisation des OOP?
2. De combien le taux d'échec de vos conseillers a-t-il diminué grâce à l'utilisation de la POO ?
1. Pas de combien. La rentabilité ne dépend pas de l'OOP.
2. A mon avis, d'un ordre de grandeur (décuplé). Mais le principal avantage de la POO réside dans le support du code. Maintenant, je suis très rapide pour comprendre le code que j'ai écrit il y a un an ou plus. Je me souviens bien de la façon dont j'ai compris mes premiers programmes ANSI C dans un style purement procédural. C'était beaucoup plus difficile.
Le débogage est facilité précisément par la division des responsabilités dans chaque classe : chaque classe est responsable de son propre ensemble de variables. Aucune autre classe n'a le droit de changer ses valeurs. Par conséquent, la plupart des problèmes sont déjà éliminés au stade de la compilation. Et l'accès aux variables depuis n'importe quel endroit du programme peut être comparé à une douzaine de volants sur un navire.
Je ne comprends pas pourquoi je n'ai JAMAIS rencontré une telle chose dans mon travail. Pourquoi les problèmes de délimitation des accès aux variables par UN seul développeur dans un programme pas très grand ? Il y aurait 100 développeurs, chacun écrivant 100 fonctions. Théoriquement, on pourrait l'inventer. Mais pratiquement la programmation a évolué vers la POO depuis presque 40 ans, des montagnes de code ont été écrites et on n'a jamais rien entendu de tel.