Programmation OOP vs programmation procédurale - page 37

 
Andrei:

Une classe n'a que des variables internes et aucune variable d'entrée ou de sortie... Où avez-vous vu l'utilisation en programmation d'un tel objet qui n'a aucun contact avec le monde extérieur et qui bout dans son propre jus ?


+100

 

La discussion me rappelle une vidéo que les gars ont montré récemment :)


 
Andrei:

La classe n'a que des variables internes et aucune entrée et sortie... Où avez-vous vu l'utilisation en programmation d'un tel objet, qui n'a aucun contact avec le monde extérieur et qui cuit dans son propre jus ?

La classe dispose d'une interface par laquelle elle interagit avec le monde extérieur. Elle nous permet de couper toutes les choses "inutiles" qui ne sont pas destinées à des blocs extérieurs.

Par exemple, dans mon processeur de transaction, j'ai des variables, dont certaines sont destinées à MT4, d'autres à MT5 et d'autres encore aux deux plateformes. Mais toutes ces variables sont absolument inutiles à toute partie de mon TS. Respectivement, ils n'y ont pas accès. Toutes les parties du TS reçoivent une interface virtuelle du processeur commercial, dans laquelle seules les fonctions nécessaires au fonctionnement du TS sont définies, et tout ce qui n'est pas pertinent, tout ce qui dépend de la plateforme et tout ce qui est "spécifique au commerce" sont supprimés.

C'est la même chose avec une position commerciale - les parties de TS n'ont pas un accès direct à une position commerciale. Ils ne peuvent obtenir qu'une interface virtuelle qui permet de compter le nombre de composants commerciaux ouverts, et les données de chaque composant. Mais le TS ne sait même pas ce qu'il traite, qu'il s'agisse d'un ordre MT4 ou d'une position MT5. Tout cela lui est caché. Le TS ne devrait pas avoir accès aux variables utilisées pour traiter les ordres MT4 ou les positions MT5, et il ne l'a pas.

 
George Merts:

La classe dispose d'une interface par laquelle elle interagit avec le monde extérieur. Il vous permet de couper tout ce qui est "superflu" et qui n'est pas destiné aux blocs externes.

Ici, en particulier, dans mon processeur de transaction - j'ai des variables, dont certaines sont pour MT4, d'autres pour MT5, d'autres pour les deux plateformes. Mais toutes ces variables sont absolument inutiles à toute partie de mon TS. Respectivement, ils n'y ont pas accès. Toutes les parties du TS reçoivent une interface virtuelle du processeur de négociation, dans laquelle seules les fonctions nécessaires au fonctionnement du TS sont définies, et toutes les choses inutiles, toutes celles qui dépendent de la plate-forme et sont "spécifiques au commerce", sont supprimées.


Soyons très précis et donnons un exemple très clair.

1. cotier à l'entrée

2. il y a une commande d'achat/vente sur la sortie.

3. L'entrée est convertie en sortie par l'intersection de deux lingettes.

Quelles sont les OOP entre eux et pourquoi ?

 
СанСаныч Фоменко:

Expliquez cela aux métaquotes : pourquoi ont-ils écrit d'énormes manuels pour le terminal, pour le langage et en général, où est née cette montagne de documentation pour les produits logiciels sur par exemple Cp.... En fait, existe-t-il des produits logiciels sans documentation ? C'est étrange que vous ne le voyiez pas.


Malheureusement, vous mélangez encore les choses. Le manuel d'un programme n'est pas une documentation. Au siècle dernier, ils tenaient une documentation et obéissaient aux normes de l'État. Maintenant, nous n'avons pas besoin de tout ça. Maintenant, nous n'avons que les TDR. La documentation se compose désormais de cas de test et d'interfaces de classe. Bien entendu, les classes sont nommées de manière à ce que leur nom seul indique clairement ce qu'elles font et dans quel but elles sont utilisées.

 
Ihor Herasko:

Malheureusement, vous confondez encore une fois les termes. Un manuel de programme n'est pas une documentation. Au siècle dernier, il y avait de la documentation, et ils suivaient les GOSTs et ainsi de suite. Tout cela est inutile maintenant. Il ne reste plus que les termes de référence. La documentation se compose désormais de cas de test et d'interfaces de classe. Et bien sûr, les classes sont nommées de manière à ce que nous puissions comprendre par leur nom ce qu'elles font et dans quel but elles sont utilisées.

La documentation a été conservée au siècle dernier, nous avons obéi aux normes de l'État, etc. C'est inutile maintenant.

Je suis tout à fait d'accord avec vous sur ce point, car ils n'écrivent rien de sérieux.

Il y a toujours eu les TdR. Mais ces programmes simples dont l'algorithme peut être entièrement défini en TT n'ont pas été écrits au siècle dernier et ne sont toujours pas écrits par des personnes sérieuses.

Qu'en est-il des "cas de test et des interfaces de classe" lors du développement de compilateurs ? lors de la programmation d'algorithmes mathématiques ?



PS.

Il y avait une rubrique pour les perles.

C'est dedans.

Un manuel de programme n'est pas une documentation.

 
СанСаныч Фоменко:

Prenons un exemple précis et très clair.

1. l'entrée est un quotient

2. la sortie est une commande d'achat/vente.

3. L'entrée est convertie en sortie par l'intersection de deux lingettes.

Quelles sont les OOP entre eux et pourquoi ?

C'est assez simple.

Il y a un générateur d'entrée. Il demande au conseiller expert l'interface du fournisseur de données, l'interface des positions commerciales et l'interface du processeur de transactions, puis les deux interfaces de masques sont demandées au fournisseur de données.

Lorsque OnTick() est appelé - la même fonction est appelée depuis le générateur d'entrée. Le générateur d'entrée regarde l'interface ondulée, compare sa valeur passée. S'il détecte un croisement, il consulte l'interface de la position commerciale. S'il voit que nous ne sommes pas en position, il appelle l'interface du processeur de négociation pour une fonction d'achat ou de vente. S'il voit qu'il y a une position, si la position est dans la direction requise - nous ne faisons rien, si c'est le contraire - nous appelons la fonction de fermeture de position dans l'interface de négociation et nous achetons ou vendons.

Vous devez noter que le générateur n'a accès à aucune variable, ni pour le calcul des wipes, ni pour obtenir une position de trade, ni pour ouvrir des ordres dans MT4 ou des positions dans MT5. Le fournisseur de dates ne connaît que les lingettes qui ont été demandées. Il les recalcule à chaque tic et les met à jour. Personne d'autre ne le sait. Un processeur commercial - exécute exclusivement les instructions qui lui parviennent par l'interface, et ne sait même pas de qui elles proviennent. Le conseiller expert - met à jour la position commerciale à chaque tick et la transmet à l'interface demandée, sans étudier qui en a besoin et ce qui se trouve dans ce bloc. Tous les blocs sont séparés et communiquent exclusivement par des interfaces prédéfinies.

 
СанСаныч Фоменко:

Prenons un exemple précis et très clair.

1. l'entrée est un quotient

2. la sortie est une commande d'achat/vente.

3. L'entrée est convertie en sortie par l'intersection de deux lingettes.

Quelles sont les OOP entre eux et pourquoi ?

/// применение  ООП для элементарных задач (фактически весь код)

OnInit(){

Series FAST_MA=MA(...);

Series SLOW_MA=MA(...);

OnCrossUp(FAST_MA,SLOW_MA,Buy);

OnCrossDn(FAST_MA,SLOW_MA,Sell);

}

Mais c'est de la POO en soi au sein des bibliothèques élaborées - c'est fait pour écrire facilement et simplement et en même temps pour que tout soit débogué. Il y a des interfaces "la source des cotations" et "l'exécuteur des ordres", des "séries temporelles", des "indicateurs" et beaucoup d'autres choses... Mais ce code court est prêt pour les conditions rigoureuses du marché réel, avec tous les pépins et les méchancetés.

D'un simple geste, vous pouvez prendre un quotient arbitraire (synthétique) ou l'exécuter sur un autre symbole...ou simplement commander un autre Expert Advisor (et c'est l'avantage de la POO, la complexité à l'intérieur, et le problème appliqué demande peu d'effort).

 
George Merts:

C'est assez simple.

Il y a un générateur d'entrée. Il - demande au conseiller expert l'interface du fournisseur de données, l'interface des positions commerciales et l'interface du processeur de transactions. Ensuite, deux interfaces de wagons sont demandées au fournisseur de données.

Lorsque OnTick() est appelé - la même fonction est appelée depuis le générateur d'entrée. Le générateur d'entrée regarde l'interface ondulée, compare sa valeur passée. S'il détecte un croisement, il consulte l'interface de la position commerciale. S'il voit que nous ne sommes pas en position, il appelle l'interface du processeur de négociation pour une fonction d'achat ou de vente. S'il voit qu'il y a une position, si la position est dans la direction requise - nous ne faisons rien, si c'est le contraire - nous appelons la fonction de fermeture de position dans l'interface de négociation et nous achetons ou vendons.

Vous devez noter que le générateur n'a accès à aucune variable, ni pour le calcul des wipes, ni pour obtenir une position de trade, ni pour ouvrir des ordres dans MT4 ou des positions dans MT5. Le fournisseur de dates ne connaît que les lingettes qui ont été demandées. Il les recalcule à chaque tic et les met à jour. Personne d'autre ne le sait. Un processeur commercial - exécute exclusivement les instructions qui lui parviennent par l'interface, et ne sait même pas de qui elles proviennent. Le conseiller expert - met à jour la position commerciale à chaque tick et la transmet à l'interface demandée, sans étudier qui en a besoin et ce qui se trouve dans ce bloc. Tous les blocs sont séparés et ne communiquent que par des interfaces prédéfinies.


Incroyable !

Je me demandais : existe-t-il une autre possibilité dans la programmation moderne pour brouiller le problème du niveau de l'œuf de manière plus abrupte ?

 
Maxim Kuznetsov:

/// применение  ООП для элементарных задач (фактически весь код)

OnInit(){

Series FAST_MA=MA(...);

Series SLOW_MA=MA(...);

OnCrossUp(FAST_MA,SLOW_MA,Buy);

OnCrossDn(FAST_MA,SLOW_MA,Sell);

}

Mais la POO elle-même se trouve à l'intérieur des bibliothèques développées - elle est faite pour écrire facilement et simplement et tout est ajusté à cela. Il y a des interfaces "source de cotation" et "exécuteur d'ordres", des "séries temporelles", des "indicateurs" et bien d'autres choses encore... Mais ce code court est prêt à affronter les conditions réelles du marché, avec tous les problèmes et les désagréments.

D'un simple geste, vous pouvez prendre un quotient arbitraire (synthétique) ou l'exécuter sur un autre symbole...ou simplement commander un autre Expert Advisor (et c'est l'avantage de la POO, la complexité à l'intérieur, et le problème appliqué demande peu d'effort).


MonOnInit() ressemble à peu près à la même chose - une douzaine de lignes...

Et alors ?

Raison: