Programmation OOP vs programmation procédurale - page 27
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
En programmation fonctionnelle-procédurale, les problèmes d'accès que vous décrivez n'existent pas. Sans surcharge de fonctions, sans champs et objets, sans pointeurs et autres, lorsque vous n'avez qu'une seule mémoire pour toutes les variables globales auxquelles vous pouvez accéder de n'importe où, comment la mauvaise fonction peut-elle être appelée ? Quels types d'erreurs d'accès peuvent survenir ? Et c'est beaucoup plus facile de se souvenir de tout.
Il s'agit d'une simple erreur - se référer à la mauvaise variable contenant une valeur proche.
Une telle erreur peut passer inaperçue pendant très longtemps, mais, par la loi de la méchanceté, elle "surgit" juste au moment où un travail sans erreur dans ce lieu serait très nécessaire !
Et ça va être très difficile de comprendre... Vous essayez de comprendre pourquoi le Conseiller Expert a fermé une transaction dans une bonne tendance alors que TS n'aurait pas dû la fermer - et vous n'y arrivez pas. Tout semble fonctionner correctement.
C'est exactement l'une des erreurs les plus désagréables - la non-initialisation des variables, ou l'adressage de la mauvaise variable, mais proche par la valeur. Et plus il y a de variables disponibles dans telle ou telle partie du programme - plus la probabilité de cette erreur est grande.
Oui, bien sûr, si vous avez un noyau graphique globalement accessible, et que vous travaillez avec des commandes, il est vraiment difficile d'accéder à la mauvaise variable. Mais dans un bloc antérieur où vous détectez la nécessité d'ouvrir un ordre et d'adresser des indicateurs à cette fin et probablement en fonction des actions de l'utilisateur - il est tout à fait réel de mélanger les variables.
S'il y a plus de structures et que des détails importants disparaissent périodiquement de la mémoire, vous arriverez à la conclusion que l'accès global est une source de problèmes et que vous devez éviter de l'utiliser à tout prix. Et que le code doit être écrit de manière à ce que vous vous en souveniez le moins possible. Idéalement, il ne faut rien garder en mémoire - chaque bloc a un nom, indiquant sa fonction, à l'entrée il reçoit les données nécessaires et suffisantes pour cette fonction, il ne reste plus qu'à mettre en œuvre la fonction sans faire intervenir d'autres connaissances "de l'extérieur".
Il s'agit d'une simple erreur - se référer à la mauvaise variable contenant une valeur proche.
Une telle erreur peut passer inaperçue pendant très longtemps, mais, par la loi de la méchanceté, elle "surgit" juste au moment où un travail sans erreur dans ce lieu serait très nécessaire !
Et ça va être très difficile de comprendre... Vous essayez de comprendre pourquoi le Conseiller Expert a fermé une transaction dans une bonne tendance alors que TS n'aurait pas dû la fermer - et vous n'y arrivez pas. Tout semble fonctionner correctement.
C'est exactement l'une des erreurs les plus désagréables - la non-initialisation des variables, ou l'adressage de la mauvaise variable, mais proche par la valeur. Et plus il y a de variables disponibles dans telle ou telle partie du programme - plus la probabilité de cette erreur est grande.
Oui, bien sûr, si vous avez un noyau graphique globalement accessible, et que vous travaillez avec des commandes, il est vraiment difficile d'accéder à la mauvaise variable. Mais dans un bloc antérieur où vous détectez la nécessité d'ouvrir un ordre et d'adresser des indicateurs à cette fin et probablement en fonction des actions de l'utilisateur - il est tout à fait réel de mélanger les variables.
S'il y a plus de structures et que des détails importants disparaissent périodiquement de la mémoire, vous arriverez à la conclusion que l'accès global est une source de problèmes et que vous devez éviter de l'utiliser à tout prix. Et que le code doit être écrit de manière à ce que vous vous en souveniez le moins possible. Idéalement - ne rien stocker du tout en mémoire - chaque bloc a un nom, indiquant sa fonction, à l'entrée il reçoit les données nécessaires et suffisantes pour cette fonction, il ne reste plus qu'à mettre en œuvre la fonction, n'impliquant aucune autre connaissance "de l'extérieur".
Eh bien, comment pouvez-vous appeler la mauvaise variable, si elles ont toutes des noms différents ? Comment une fonction erronée peut-elle être appelée si elle a un nom unique et aucune surcharge ? Dans le tableau du noyau, tous les index des cellules sont nommés avec des mots humains. Qu'est-ce qui pourrait être confus ici ? Comprenez que les problèmes dont vous parlez n'existent pas du tout.
Je ne garde en mémoire que la structure du noyau, qui est très simple. Je connais aussi la liste des propriétés des objets. Tous les objets ont les mêmes propriétés, seules les valeurs sont différentes. J'ai un total de 140 propriétés, mais je ne garde en mémoire que les plus importantes, environ 30. Le reste, je m'en souviens quand j'en ai besoin. Pour ce faire, j'ouvre un fichier avec des définitions et je regarde la liste complète des propriétés. Rien de compliqué. Les variables globales en cours de traitement, comme par exemple "OBJECT" ou "WINDOW", ne doivent pas être mémorisées du tout. Et il est impossible de le mélanger avec autre chose.
Mes variables ont des noms significatifs en russe. On ne peut que confondre les choses après une fête sauvage).Mes variables globales sont les variables utilisées dans le focus, qui sont "ciblées" sur le noyau et déplacées en fonction des mouvements du curseur.
Par exemple, la variable "WINDOW" porte en permanence le numéro de la fenêtre dans laquelle se trouve le curseur. La variable "OBJECT" est le numéro de l'objet où se trouve le curseur.
Je m'adresse à une fenêtre, un objet et une propriété particuliers dans le noyau par leur intermédiaire - G_CORE[WINDOW][OBJECT][_NAME] ou G_CORE[WINDOW][OBJECT][_OBJECT_GROUP]. Dans toute fonction, si je veux la coordonnée X d'un objet, je l'obtiens de G_CORE[WINDOW][OBJECT][_X], si je veux la hauteur d'un objet - de G_CORE[WINDOW][OBJECT][_Y_SIZE] etc...
En tout, j'ai environ une centaine de variables globales déclarées séparément, mais il y en a des milliers dans le tableau global du noyau, car chaque cellule du tableau est une variable. Cependant, il est très facile de gérer ce nombre de variables, car elles sont ordonnées. Chaque fenêtre du noyau est un champ de tableau ; chaque ligne est un objet, qui se compose de 140 propriétés. Les éléments, dans ce cas, sont des ensembles d'objets. Chaque élément possède un objet maître, qui contient les principales propriétés de l'élément entier. Les objets appartenant à chaque élément sont liés par des indices spéciaux. Ainsi, quel que soit l'objet mis au point, l'élément auquel il appartient l'est également. Il en va de même pour la toile sur laquelle il est dessiné. Grâce à l'archétype explicite du noyau et à l'accès direct à partir de n'importe quelle fonction, je peux gérer des milliers de variables qui sont représentées par des cellules de tableau du noyau sans rien oublier et sans devoir naviguer autour d'elles.
Une conversation totalement inutile : il n'existe aucun critère permettant de classer un code comme "bon" ou "mauvais". C'est pourquoi il n'est pas clair sur la POO.
Pour moi, ce critère est la FAISABILITÉ du code, qui se manifeste par le fait que l'auteur ou un tiers peut lire le code et l'utiliser pour le modifier, en recherchant les bogues après une période de temps assez longue......
Ici, au-dessus, Fedoseyev a remplacé l'interrupteur OOP. Cet exemple particulier, peut-être malheureux, est pour moi une preuve de la méchanceté de la POO : un code clair avec un interrupteur à 100 positions est remplacé par une seule ligne. Pour comprendre cette ligne, il faut aller quelque part. Ce n'est pas admissible pour moi.
Le deuxième exemple ci-dessuspar George Merts
Lorsque le code clair a été remplacé par un code NON clair après le débogage. Selon mon critère, le code de qualité (facile à lire) a été remplacé par le code qui n'est pas acceptable pour moi.
C'est pourquoi j'ai une question pour tous les partisans de la POO : est-ce qu'un programme devient plus vivant quand la POO est appliquée et l'exemple donné par Fedoseyev sur le commutateur est un échec ou au contraire, l'exemple de Fedoseyev caractérise très précisément la POO et la POO conduit presque toujours à une perte de vivacité ?
Eh bien, tout est clair avec CC. Tout ce qui est au-dessus du niveau de sa compréhension est inesthétique. Mais il connaît la lettre R ))))))))))))))
Eh bien, le CC est clair. Tout ce qui dépasse son niveau de compréhension est inintéressant. Mais il connaît la lettre R ))))))))))))))
Je vais ajouter le chinois, peut-être le japonais...
Pourquoi l'OLP ? POURQUOI ce serait mieux ?
La visibilité permet de simplifier le débogage et la modification. La visibilité vient d'une conception soignée du programme, d'une structuration en FONCTIONS et non en OBJETS, car le monde entier est basé sur des actions sur des objets, mais pas l'inverse.
Lorsque la décomposition en fonctions est dérivée de la séquence de conversion des entrées en sorties. Par exemple, la conversion d'une entrée BUY|SELL en une sortie n'est possible qu'en spécifiant une ACTION.
C'est ainsi que fonctionne la pensée humaine.
PS.
En ce qui concerne votre commentaire sur R.
Tu veux être sarcastique ?
Je réponds très rarement, mais je peux.
Comment diable pouvez-vous appeler la mauvaise variable si elles ont toutes des noms différents ? Comment la mauvaise fonction peut-elle être appelée si elle a un nom unique et pas de surcharge ? Dans le tableau du noyau, tous les index des cellules sont nommés avec des mots humains. Qu'est-ce qui pourrait être confus ici ? Comprenez que les problèmes dont vous parlez n'existent pas du tout.
Eh bien, j'ai eu quelques cas de ce genre.
Le plus souvent, ces erreurs se produisent lorsque vous copiez un morceau de code d'un autre endroit et que vous le "corrigez" en fonction du bloc actuel. Si vous disposez d'un accès global, vous risquez de ne pas modifier l'une des variables. Si vous n'avez accès qu'à ce avec quoi vous devez travailler dans ce cas - alors après la copie - le compilateur lui-même vous donne une liste de toutes les variables et emplacements qui doivent être modifiés.
Tag Konow:
Je n'ai en mémoire que la structure du noyau, qui est très simple. Je connais également la liste des propriétés des objets. Les propriétés de tous les objets sont les mêmes, seules les valeurs sont différentes. J'ai un total de 140 propriétés, mais je ne garde en mémoire que les plus importantes, environ 30. Le reste, je m'en souviens quand j'en ai besoin. Pour ce faire, j'ouvre un fichier avec des définitions et je regarde la liste complète des propriétés. Rien de compliqué.
30 propriétés ? ?? Eh bien, c'est inacceptable pour moi. Non pas que je ne m'en souvienne pas, mais je ne veux pas me fier à ma mémoire. Bien mieux, lorsque dans chaque bloc - vous avez toujours exactement les variables, qui dans ce bloc doivent être traitées, et il n'y a pas d'accès aux autres.
Mais ça me stresse d'avoir à me souvenir... Et puisque ce n'est pas difficile pour vous, il est compréhensible qu'il n'y ait aucun intérêt à faire des manipulations OOP inutiles.
Eh bien, j'ai eu quelques cas de ce genre.
L'erreur la plus courante de ce type se produit lorsque vous copiez un morceau de code d'un autre endroit et que vous le "corrigez" pour qu'il corresponde au bloc actuel. Si vous disposez d'un accès global, vous pouvez très bien ne pas modifier l'une des variables. Si vous n'avez accès qu'à ce avec quoi vous devez travailler dans ce cas - alors après la copie - le compilateur lui-même vous donne une liste de toutes les variables et emplacements qui doivent être modifiés.
30 propriétés ? ?? Eh bien, ce n'est pas acceptable pour moi. Ce n'est pas que je ne m'en souvienne pas, mais je ne veux pas me fier à ma mémoire. Bien mieux, lorsque dans chaque bloc - vous avez toujours exactement les variables, qui dans ce bloc doivent être traitées, et il n'y a pas d'accès aux autres.
Mais ça me stresse d'avoir à me souvenir... Et puisque ce n'est pas difficile pour vous, il est compréhensible qu'il n'y ait pas besoin de faire des transactions OOP inutiles.
Eh bien, franchement, je me souviens de beaucoup de choses. Il suffit de regarder les abréviations des objets snapping _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C etc... chacun définit la position d'un objet par rapport à l'autre. On les retrouve dans les paramètres A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... Je me souviens également de quelques dizaines de noms de catégories et sous-catégories d'objets, de quelques dizaines de propriétés de fenêtres (plus de 100). Il y a des dizaines de fonctions dans le bloc de construction, par exemple, et elles occupent plus de 4000 lignes de code. Vous devez naviguer et vous souvenir de beaucoup d'entre eux. Mais se souvenir vient d'une longue pratique, pas d'un coup, mais progressivement. J'avais l'habitude d'avoir la tête lourde à cause de la quantité d'entités et de la taille du code, mais ensuite tout s'enlisait et devenait simple.
Eh bien, franchement, je me souviens de beaucoup de choses. Les abréviations des références des objets _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C, etc... Chacun définit une certaine position d'un objet par rapport à un autre, sont en paramètres A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... Je me souviens également de quelques dizaines de noms de catégories et sous-catégories d'objets, de quelques dizaines de propriétés de fenêtres (plus de 100). Il y a des dizaines de fonctions dans le bloc de construction, par exemple, et elles occupent plus de 4000 lignes de code. Vous devez naviguer et vous souvenir de beaucoup d'entre eux. Mais se souvenir vient d'une longue pratique, pas d'un coup, mais progressivement. J'avais l'habitude de me gonfler la tête avec le nombre d'entités et la taille du code, mais ensuite tout s'est enlisé et est devenu simple.
Pour me distraire, en oubliant tout, partir en vacances pendant un mois sans penser au code. Puis revenir, voir tous ces a1, b1, etc. et devenir hystérique :)
se laisser distraire, oublier tout, partir en vacances pendant un mois, sans penser au code. Après être venu, voir tous ces a1, b1, etc. et devenir hystérique :)
Par exemple, voici à quoi ressemble l'élément "checkbox" dans le proto-core :