Une question pour les experts de la POO. - page 16
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
C'est vrai, plus sur cette fonction. Vous avez un interrupteur de taille monstrueuse qui sélectionne l'une des dizaines de 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 quand 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 d'autres, qui ne peuvent pas se souvenir d'autant de choses, il est beaucoup plus raisonnable de se souvenir de l'ensemble du mouvement, et de ce qui arrive aux muscles, dans quelle séquence ils sont tendus et dans quelle mesure - il est plus raisonnable de le cacher à l'esprit.
Oui, George, vos arguments sont raisonnables et logiques. En effet, mon approche vous oblige à vous souvenir et à connaître tout ce que contient votre programme. C'est à la fois bon et mauvais. Bon, parce que savoir assure un développement rapide du code et des solutions, peu de syntaxe et beaucoup de fonctionnalité, et mauvais, parce qu'il n'y a aucune disposition pour la portabilité des parties du code à d'autres programmes en raison de l'interconnexion globale de tous les blocs.
Notre langue parlée, après tout, utilise également la mémoire globale. Nous connaissons et nous nous souvenons de tous les mots et pas seulement de ceux qui appartiennent au sujet de conversation actuel. Tout est mélangé dans nos esprits. C'est comme ça que l'esprit fonctionne, et c'est comme ça que mon approche fonctionne. Tous les résultats les plus importants des unités fonctionnelles sont universellement disponibles. Et donc, en eux se trouve une terminologie presque humaine. Je parle en code, comme une langue normale. C'est très pratique. Mais, il y a beaucoup de choses à retenir. C'est vrai.
ZS. Au fait, le commutateur géant peut être décomposé en fichiers et son contenu caché. C'est juste pratique pour moi de voir tout ça.
Tinny, tu fais une sorte de construction de vélo sans avoir étudié correctement l'approche conventionnelle. Peter, trouvez un bon livre, peut-être Stroustrup, dans un livre il a écrit un éditeur de texte, vous apprendrez quelque chose à partir d'un vrai problème, je ne me souviens pas du contenu, mais il est peu probable qu'il vous enseigne de mauvaises choses.
Merci, bien sûr. Mais il est peu probable que des tâches spécifiques m'ouvrent les yeux sur quoi que ce soit, car j'en ai résolu une myriade au cours des six dernières années. Une véritable myriade. Donc je sais de quoi je parle.
Il y a beaucoup de tâches, et vous n'avez toujours pas compris l'utilité de la surcharge. Imaginez qu'une fonction modèle, ses arguments peuvent passer par le type int, double ou utilisateur, et que nous voulons trouver une valeur absolue par abs(), comment pouvons-nous le faire sans surcharge ?
J'aimerais voir vos béquilles autour de ces tableaux lorsque le projet prendra de l'ampleur : simuler une roue de voiture -> voiture avec 4 buggys -> route avec une centaine de voitures.
Et maintenant, l'efficacité. L'échange est quoi au final ? Il s'agit d'une comparaison séquentielle d'un paramètre avec les constantes. Attention Peter, séquentiel.
Non, l'interrupteur fonctionne différemment. Il s'agit d'un tableau dans lequel l'interrupteur passe directement à la constante souhaitée. C'est une différence importante par rapport au bloc if.
Et maintenant, l'efficacité. L'échange est quoi au final ? C'est une comparaison séquentielle d'un paramètre à des constantes. Attention Peter, séquentiel. Autrement dit, si la constante recherchée est 100500, toutes ces comparaisons seront effectuées sur le processeur. Que sont les fonctions/méthodes surchargées ? Ce sont des blocs de code complètement différents dans le code machine après la compilation, avec leurs propres points d'entrée. Alors, lequel est le plus efficace ?
Hélas, l'inévitable surenchère. Dans ce cas, je perds, dans l'autre, je gagne.
Par exemple, la fonction avec l'interrupteur géant effectue le positionnement des objets dans les articles et des articles dans les fenêtres. Il calcule leurs tailles. Je l'appelle une fois et tous les éléments et tous les objets sont placés à leurs positions en fonction de leurs points d'ancrage. Il calcule leur taille et leur position les uns par rapport aux autres, détermine les éléments à masquer, la taille requise pour le kanvas, etc. Un appel est un travail énorme. Le même bloc peut calculer la taille ou la position d'un élément de fenêtre parmi des milliers. Un bloc. L'appel est Object() ;
Combien de classes et de fonctions devrais-je écrire en POO pour résoudre un tel nombre de tâches ? J'ai peur d'imaginer.
Hélas, l'inévitable surenchère. Dans ce cas, je perds, dans l'autre, je gagne.
Par exemple : la même fonction avec un interrupteur géant effectue le positionnement des objets dans les éléments et des éléments dans les fenêtres. Je l'appelle une fois et tous les éléments et tous les objets sont placés à leur position en fonction de leurs liens. Leurs tailles et leurs positions sont calculées. Il est déterminé quels éléments doivent être cachés, quelle est la taille requise pour le kanvas et ainsi de suite... Un appel est un travail énorme. Le même bloc peut calculer les tailles ou les positions d'un élément de fenêtre parmi des milliers. Un bloc.
Combien de classes et de fonctions devrais-je écrire en POO pour résoudre un tel nombre de tâches ? J'ai peur d'imaginer.
Non, l'interrupteur fonctionne différemment. Il s'agit d'un tableau dans lequel l'interrupteur passe directement à la constante souhaitée. C'est la différence essentielle entre le bloc "if" et le bloc "it".
Nous créons une fonction sans paramètres, écrivons tous les calculs des fonctions surchargées à l'intérieur, rendons les variables globales et avons accès aux résultats de toute autre fonction. Eh bien, c'est une beauté, n'est-ce pas ?