Une question pour les experts de la POO. - page 17
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
Je veux dire le nombre de classes. Chacune d'elles compte 200 lignes.
L'accès serait-il beaucoup plus difficile ? J'ai un noyau global qui est visible de partout. En OOP, je devrais y renoncer. Comment puis-je travailler avec des éléments dans Windows ? Je deviens comateux quand j'essaie de l'imaginer.))
Classe statique.
Vladimir Simakov:
А теперь к эффективности. Switch - это что в конечном итоге? Это последовательное сравнение параметра с константами. Внимание Петр, последовательное.
pas du tout nécessaire.
Cela ne signifie pas que Peter a raison ou que l'interrupteur doit être placé partout, mais néanmoins.
Oui, c'est vrai,donc en termes de vitesse, c'est évidemment l'option la plus rapide de MQL. Mais l'accès auxobjets de classe dans l'environnement géré est indirect.
C'est vrai, plus sur cette fonction. Vous avez un interrupteur de taille monstrueuse qui sélectionne l'une des douze fonctions dont vous avez besoin. Dans un tel commutateur, il est très facile de faire une erreur en écrivant accidentellement le code relatif à l'une des branches au mauvais endroit.
Les choses sont beaucoup plus simples avec une surcharge. Nous avons dix descendants différents, et à chaque fois nous travaillons avec UNE classe, et elle a UNE fonction surchargeable. Nous ne pouvons pas l'écrire accidentellement dans une autre classe, car nous devons ouvrir un fichier complètement différent pour cela.
De plus, l'analyse syntaxique elle-même dans ce très grand commutateur est, à mon avis, beaucoup plus stressante que l'ouverture de la seule classe dont nous avons besoin, puis l'analyse syntaxique d'une seule fonction.
En fait, en code assembleur, toutes les manipulations de ce commutateur se résument de toute façon au même commutateur, dépendant de ce pointeur. Mais dans le cas de la POO, tout cela est caché au programmeur et n'interfère pas avec son travail. Sans OOP - vous devez faire avec.
En gros, lorsque vous marchez, vous envoyez des signaux à vos muscles dans un certain ordre pour les faire bouger. Cependant, au niveau de la conscience, vous vous souvenez simplement du mouvement à faire. Ici, la POO est exactement ce genre de "mémoire du mouvement à faire". Vous "ne comprenez pas pourquoi nous avons besoin de nous souvenir du mouvement alors que nous avons un tas de muscles, et des nerfs connectés à eux". eh bien... Je l'ai déjà dit à plusieurs reprises, pour les titans de la mémorisation, il suffit de se rappeler quels muscles doivent être tendus et dans quel ordre. Il est inutile de se souvenir de l'ensemble du mouvement. Pour les autres, qui ne peuvent pas se souvenir de tant de choses, il est beaucoup plus raisonnable de se souvenir de l'ensemble du mouvement, et de ce qu'il y a avec les muscles, dans quelle séquence ils sont tendus et dans quelle mesure - il est plus raisonnable de le cacher à l'esprit.
Les fonctions surchargées sont juste des fonctions différentes pour le compilateur, et pas de commutateur.
Et combien plus difficile serait l'accès ? J'ai un noyau global qui est visible de partout. En OOP, je devrais y renoncer. Comment travailler avec les éléments dans les fenêtres alors ? Je deviens comateux quand j'essaie de l'imaginer.))
Pourquoi ?
Le noyau global et la POO ne s'excluent pas mutuellement.
Seuls les éléments des fenêtres devraient être encapsulés à l'intérieur des classes de fenêtres, et non pas "Laying on view". Juste pour que personne ne puisse accidentellement "se mettre au mauvais endroit". Il est très facile de modifier une variable et de se tromper sur son emplacement dans un énorme tableau global, alors qu'il est beaucoup plus difficile d'interroger la bonne interface, puis de modifier la même variable dans le bon objet et de se tromper.
Les fonctions surchargées pour le compilateur sont simplement des fonctions différentes, et pas de switch.
Et comment choisit-on celui qui est nécessaire ? Nous parlons de fonctions virtuelles et de late binding. Quelle fonction surchargée sera appelée ? Ceci est déterminé par le pointeur this, qui est passé implicitement lorsque vous l'appelez. Et comment pensez-vous que ce choix est fait ?
Et comment choisit-on celui que l'on veut ? Nous parlons de fonctions virtuelles et de liaisons tardives. Quelle fonction surchargée sera appelée ? Ceci est déterminé par le pointeur this, qui est implicitement passé dans l'appel. Et comment pensez-vous que ce choix est fait ?
En fait, Peter ne parlait pas de fonctions virtuelles.
Mais ils n'ont pas non plus d'interrupteurs.
Une classe qui possède des fonctions virtuelles possède une table de fonctions virtuelles.
Et chaque objet de cette classe contient une variable implicite - un pointeur vers la table des fonctions virtuelles.
Si une ou toutes les fonctions virtuelles sont surchargées dans le descendant, un nouveau tableau est créé et les instances descendantes contiennent un pointeur vers celui-ci.
En fait, Peter ne parlait pas de fonctions virtuelles.
Mais ils n'ont pas non plus d'interrupteurs.
Une classe qui possède des fonctions virtuelles possède une table de fonctions virtuelles.
Et chaque objet de cette classe contient une variable implicite - un pointeur vers la table des fonctions virtuelles.
Si une ou toutes les fonctions virtuelles sont surchargées dans le descendant, un nouveau tableau est créé et les instances du descendant contiennent un pointeur vers celui-ci.
Exactement. Je demande, comment fonctionne cette même table ? En code assembleur, c'est le même interrupteur.
Et à propos de "ne pas parler des fonctions virtuelles" - c'est un peu comme "pourquoi la POO"... C'est-à-dire qu'il s'agit de fonctions virtuelles, et non de simples noms de fonctions identiques avec des arguments différents.
Exactement. Ma question est donc la suivante : comment fonctionne ce tableau ? En code assembleur, c'est le même interrupteur.
Non. C'est juste un tableau de pointeurs vers une fonction.
Le code d'assemblage prend une adresse de table de l'objet.
Il prend l'adresse de la fonction à une certaine position.
Et un saut vers cette adresse est effectué.
Et que dire de "Je ne parlais pas des fonctions virtuelles" - c'est ce que je voulais dire par "pourquoi la POO"... C'est-à-dire qu'il s'agit de fonctions virtuelles, et pas seulement de noms identiques de fonctions avec des arguments différents.
A en juger par sa question, il parlait de fonctions ayant des noms identiques.
Il est fort probable qu'il ne soit même pas au courant des fonctions virtuelles.