Une question pour les experts de la POO. - page 15
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
Il est sérieux !
Je suis sur le point de faire breveter mon concept. Il y a des investisseurs. Donc, c'est sérieux.
la nuit dernière, j'ai lu le fil de discussion sur le somnambulisme..... pour une raison quelconque, j'ai imaginé une longue liste de développeurs Windows - comme dans le générique de Star Wars !
et à la fin de la liste - en grosses lettres ReTeg Konow !
@Peter Konow pouvez-vous faire un sprite de texte comme celui-ci ?)Vous vous souvenez de tout dans le projet sur lequel vous travaillez en ce moment. Qu'en est-il des codes passés ? Vous souvenez-vous aussi bien de ce que vous avez écrit il y a un an ? Là où les choses ont changé, etc. Il s'agit maintenant de modifier ou de corriger votre ancien code.
Tout repose sur la mémoire phénoménale de Peter.
Et je suis d'accord, si vous vous souvenez de toutes les variables utilisées dans votre projet, quand et où elles sont modifiées, si vous trouvez facilement les endroits où la modification est incorrecte, alors cette POO n'a plus de sens. Peter, en fait, travaille au niveau de l'assembleur. Quelles que soient les astuces de POO et les modèles de conception que vous inventez, en fin de compte, tous les accès aux données sont des adresses mémoire ordinaires, et dans l'espace d'adressage alloué au processus, toutes les adresses mémoire sont entièrement accessibles. Le processeur lui-même ne sait rien de l'encapsulation.
Voilà, et c'est comme ça que Peter opère. Il fut un temps où j'étais moi-même assembleur.
La seule question est de savoir comment il parvient à rivaliser avec le processeur en termes de capacité de mémoire.
C'est grâce à la mémoire phénoménale de Peter.
...
La seule question est de savoir comment il parvient à rivaliser avec le processeur en termes de capacité de mémoire.
Alors qu'est-ce que le phénomène si nous parlons du même projet sur lequel il travaille tout le temps. Naturellement, tout programmeur aura tout cela dans sa tête en permanence.
Eh bien, alors, je ne suis pas n'importe qui. Moi aussi, je travaille principalement sur le même projet, mais je ne me souviens que de l'essentiel. Les détails tels que ce qui et à partir de quelle procédure est modifié - je ne les vois qu'au moment du développement direct. Et ensuite, si je reviens sur ce site, je passe beaucoup de temps à essayer de comprendre pourquoi il en est ainsi et pas autrement. Par conséquent, je suis un partisan de la suppression de tous les droits, de sorte qu'idéalement, à n'importe quel endroit du programme, vous n'avez accès qu'à ce que vous êtes censé faire à cet endroit.
Vous vous souvenez de tout dans le projet sur lequel vous travaillez en ce moment. Qu'en est-il des codes passés ? Vous souvenez-vous aussi bien de ce que vous avez écrit il y a un an ? Là où les choses ont changé, etc. Il s'agit maintenant de modifier ou de corriger votre ancien code.
Alexey Navoykov:
...
Non, le kung-fu ici est exactement OOP. Beaucoup de mouvements et de techniques, parmi lesquels dans un combat 10% de l'utile. Mais quels beaux styles ! Et dragon, et singe, et flamant rose et crapaud... J'ai un sambo spécifique. Vous coupez et vous obtenez le résultat.
Non, c'est OOP qui est kung fu ici. Beaucoup de mouvements et d'astuces, dont 10% seront utiles lors d'un combat. Mais quels beaux styles ! Dragon, singe, flamant rose et crapaud... J'ai un sambo spécifique. Vous coupez et vous obtenez le résultat.
Ce n'est pas le cas.
J'ai déjà dit cent fois l'utilité de l'encapsulation et des contraintes de droits.
L'utilité de l'héritage et du polymorphisme apparaît clairement lorsqu'on traite des listes d'éléments pour lesquelles il existe une interface virtuelle commune, mais dont l'implémentation est sensiblement différente.
Voici la situation la plus simple que j'ai rencontrée cette semaine : il existe une liste de structures, dont l'un des champs est une double valeur. L'idée est venue d'approximer ces valeurs en utilisant la POO.
Sans la POO, je dois soit écrire entièrement des procédures qui vont créer les SLAEs correspondants et les résoudre. Ou, si j'ai déjà un tel programme pour travailler avec un tableau de valeurs - écrire des procédures qui créeraient un tel tableau, et le passeraient à la fonction de la bibliothèque.
Avec la POO - j'hérite de la classe CLSMCore, et je surcharge les fonctions virtuelles qui renvoient des valeurs ponctuelles. Immédiatement, je peux obtenir les coefficients du polynôme d'approximation.
C'est-à-dire qu'à conditions égales (lorsque nous avons une fonction ou une classe de bibliothèque), je perdrais sans OOP en introduisant un tableau intermédiaire supplémentaire. Sans parler de la nécessité de déterminer exactement comment le remplir. (Les fonctions de récupération des valeurs - avec ou sans POO - doivent être écrites). Le principal avantage, à mon avis, est justement la simplicité du support et de la modification. Avec la POO, il y a moins à comprendre. Et au début, j'ai dépensé absolument autant d'efforts pour écrire la classe CLSMCore que je l'aurais fait pour la fonction d'approximation de la bibliothèque sans la POO.
Ce n'est pas le cas.
J'ai déjà dit cent fois l'utilité de l'encapsulation et des contraintes de droits.
L'utilité de l'héritage et du polymorphisme apparaît clairement lorsque l'on travaille avec des listes d'éléments qui partagent une interface virtuelle commune, mais dont l'implémentation est sensiblement différente.
Voici la situation la plus simple que j'ai rencontrée cette semaine : il existe une liste de structures, dont l'un des champs est une double valeur. L'idée est venue d'approximer ces valeurs en utilisant la POO.
Sans la POO, je dois soit écrire entièrement des procédures qui vont créer les SLAEs correspondants et les résoudre. Ou, si j'ai déjà un tel programme pour travailler avec un tableau de valeurs - écrire des procédures qui créeraient un tel tableau, et le passeraient à la fonction de la bibliothèque.
Avec la POO - j'hérite de la classe CLSMCore, et je surcharge les fonctions virtuelles qui renvoient des valeurs ponctuelles. Immédiatement, je peux obtenir les coefficients du polynôme d'approximation.
C'est-à-dire qu'à conditions égales (lorsque nous avons une fonction ou une classe de bibliothèque), je perdrais sans OOP en introduisant un tableau intermédiaire supplémentaire. Sans parler de la nécessité de déterminer exactement comment le remplir. (Les fonctions de récupération des valeurs - avec ou sans POO - doivent être écrites). Le principal avantage, à mon avis, est justement la simplicité du support et de la modification. Avec la POO, il y a moins à comprendre. Et au début, j'ai consacré autant d'efforts à l'écriture de la classe CLSMCore que je l'aurais fait pour la fonction d'approximation de la bibliothèque sans la POO.
Par exemple, je n'ai jamais compris l'utilité de la surcharge des fonctions. C'est absurde, n'est-ce pas ? Nous créons une fonction sans paramètres, à l'intérieur de laquelle nous écrivons tous les calculs des fonctions surchargées, nous rendons les variables globales et nous avons accès aux résultats de toute autre fonction. Eh bien, n'est-ce pas agréable !
Mais non ! Nous allons diviser tous les calculs en fonctions portant le même nom, mais avec des paramètres différents. Et nous allons faire un tas de paramètres d'entrée pour chaque fonction. Non. Ce n'est pas suffisant. Rendons les noms des paramètres illisibles. Et nous ferons toutes sortes de tableaux à passer en mélange avec eux. Et nous ferons une douzaine de ces fonctions pour que nous ayons à réfléchir à chacune d'entre elles. Et nous nous assurerons que leur accès sera crypté. Pour que la syntaxe soit plus sophistiquée. C'est du professionnalisme !
Désolé, George. J'en ai assez.
ZS. Un seul tableau global pour les résultats de 10 fonctions surchargées et une fonction sans paramètres qui fait leur travail. En quoi c'est pire que ça ? 10 fois moins de syntaxe.
Pour ma part, je n'ai jamais compris pourquoi les fonctions doivent être surchargées. C'est ridicule, n'est-ce pas ? On crée une fonction sans paramètres, on y écrit tous les calculs des fonctions surchargées, on rend les variables globales et on a accès aux résultats de n'importe quelle autre fonction. Eh bien, n'est-ce pas agréable !
Mais non ! Nous allons diviser tous les calculs en fonctions portant le même nom, mais avec des paramètres différents. Et nous allons faire un tas de paramètres d'entrée pour chaque fonction. Non. Ce n'est pas suffisant. Rendons les noms des paramètres illisibles. Et nous ferons toutes sortes de tableaux à passer en mélange avec eux. Et nous ferons une douzaine de ces fonctions pour que nous ayons à réfléchir à chacune d'entre elles. Et nous nous assurerons que leur accès sera crypté. Pour que la syntaxe soit plus sophistiquée. C'est du professionnalisme !
Désolé, George. Je suis désolé, George.
ZS. Un seul tableau global pour les résultats de 10 fonctions surchargées et une fonction sans paramètres qui fait leur travail. En quoi c'est pire que ça ? 10 fois moins de syntaxe.
C'est ça, dites-m'en plus sur cette fonction. Il y en a un avec un interrupteur de la taille d'un monstre qui permet de sélectionner une fonction parmi une douzaine. Dans un tel commutateur, il est très facile de faire une erreur en écrivant accidentellement du code appartenant à l'une des branches absentes.
Les choses sont beaucoup plus simples avec une surcharge. Nous avons dix descendants différents, et à tout moment 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 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.
Реter Konow:
Pour ma part, je n'ai jamais compris pourquoi les fonctions doivent être surchargées. C'est ridicule, n'est-ce pas ? On crée une fonction sans paramètres, on y écrit tous les calculs des fonctions surchargées, on rend les variables globales et on a accès aux résultats de n'importe quelle autre fonction. Eh bien, n'est-ce pas agréable !
Formidable, vous êtes engagé dans une sorte de construction de vélo sans avoir étudié correctement l'approche généralement acceptée. Peter, trouvez un bon livre, peut-être Stroustrup, dans un livre il a écrit un éditeur de texte, sur un vrai problème vous apprendrez quelque chose, je ne me souviens pas du contenu, mais il est peu probable qu'il vous enseigne de mauvaises choses.