Questions sur la POO dans MQL5 - page 50
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
Dimitri, dans ce cas, tu confonds probablement un peu les objectifs des modèles Gardien et Prototype, et toutes leurs combinaisons et manifestations possibles. Premièrement, Snapshot ne doit pas nécessairement copier l'objet entier, contrairement à Prototype.
Et oui, le besoin d'encapsulation se manifeste surtout dans les grands projets avec beaucoup de personnes. Pour des jouets comme la plupart d'entre eux, c'est un peu une redondance.
En fait, il s'agit de débattre sérieusement du fait qu'une valeur peut être attribuée à une variable et qu'elle peut ensuite être utilisée. Ah oui, lorsqu'on programme n'importe quoi sur n'importe quoi, il arrive souvent que des valeurs différentes soient attribuées à des variables différentes et qu'elles soient ensuite utilisées. Mais maintenant, on l'appelle différemment, et quand on en parle, il faut froncer les sourcils et prendre un air sérieux.
Et il est important de ne pas faire d'erreur, si tous les champs sont sauvegardés, c'est Prototype, et si ce n'est pas le cas, c'est Keeper, sinon les gars vont rire.
Vous ne faites pas partie de la secte "ils installent l'internet, nous n'en avons pas besoin, nous n'avons pas besoin de votre internet...", n'est-ce pas ? ? ??
1. le gardien, de par sa conception, est similaire au modèle qu'ils utilisent pour stocker l'état lorsqu'ils tapent avec un contenu modifiable pour annuler les changements lorsque ces changements ne sont pas un mais plusieurs centaines. Par exemple, un éditeur de photos, un éditeur de texte...
Je l'ai trouvé après avoir écrit -https://refactoring.guru/ru/design-patterns/memento
2. fondamentalement, c'est une mauvaise pratique de ne pas connaître et de ne pas comprendre le sujet pour y critiquer quelque chose...
3. Comment quelque chose que vous ne comprenez déjà pas peut-il devenir plus confus et difficile à comprendre ?
4. Le reste dépend de vous...
Qu'est-ce que le GOP a à voir avec ça ?
Par hasard, ne seriez-vous pas membre de la secte "ils installent intinet, nous n'en avons pas besoin, vous intinet" ? ? ??
1. le gardien, de par sa conception, est similaire au modèle qu'ils utilisent pour stocker l'état lorsqu'ils tapent avec un contenu modifiable pour annuler les changements lorsque ces changements ne sont pas un mais plusieurs centaines. Par exemple, un éditeur de photos, un éditeur de texte...
Je l'ai trouvé après avoir écrit -https://refactoring.guru/ru/design-patterns/memento
2. fondamentalement, c'est une mauvaise pratique de ne pas connaître et de ne pas comprendre le sujet pour y critiquer quelque chose...
3. Comment quelque chose que vous ne comprenez déjà pas peut-il devenir plus confus et difficile à comprendre ?
4. Le reste dépend de vous...
Je suis avec vous sur toute la ligne ! Merci d'avoir défendu mon point de vue... J'étais trop paresseux))
J'ajouterais seulement au point 1 que le snapshot ne stocke pas nécessairement toutes les données de l'objet, et qu'il peut y avoir plusieurs branches avec des centaines de snapshots du même objet "de différents côtés". Dans ce cas, le stockage de centaines de copies de données inutilisées est vraiment la pire des pratiques.
Nous en sommes arrivés à parler sérieusement de la façon dont on peut attribuer une valeur à une variable et l'utiliser ensuite. Oh oui - quand on programme n'importe quoi dans n'importe quoi, il arrive souvent que des valeurs différentes soient assignées à des variables différentes, puis qu'elles soient utilisées. Mais maintenant, on l'appelle différemment, et quand on en parle, il faut froncer les sourcils et prendre un air sérieux.
Et il est important de ne pas faire d'erreur, si tous les champs sont sauvegardés, alors c'est le Prototype, et si tous ne le sont pas, alors le Gardien, ou les garçons vont rire.
Dmitry, je vous assure, je serais heureux de rire de vous, enfin, j'adore ça) mais dans ce cas, vous avez exagéré, même particulièrement bien souri.
Vous êtes juste très confus - une PRISE DE VUE n'est pas égale à une COPIE D'OBJET, je vous l'ai fait remarquer.
Si ce n'est pas clair, laissez-moi vous expliquer par un exemple : vous avez 1000 octets d'objet, vous avez besoin de 200 pour l'instantané, alors pourquoi en copier 800, surtout si vous avez plusieurs millions d'instantanés enregistrés.
p/s/ Et en général. Les gens ne se rendent-ils pas compte que les modèles ne sont qu'un exemple élémentaire de la résolution d'un problème TYPIQUE élémentaire ? Et en fait, les tâches ne sont pas élémentaires, mais plus compliquées. Et pour résoudre des problèmes réels, les modèles sont nécessaires, mais souvent pas sous forme de livre pur, mais adaptés à une tâche particulière, éventuellement combinés entre eux, éventuellement avec l'ajout d'une certaine improvisation, exprimée parfois dans une simplification, si la tâche le permet, ou vice versa "pondération" de la réalisation.
Encore une fois, pourquoi avez-vous besoin de l'encapsulation et des interfaces - cela ne peut probablement pas être compris si votre QI est inférieur à celui de Wasserman, ou si vous n'avez pas participé à de vrais projets, lorsque différentes parties du projet sont modifiées par différentes personnes simultanément, et que ne pas suivre les principes de base de l'OOPD implique des coûts énormes pour attraper les bogues. Vraiment, pourquoi tout cela pour estampiller les EAs pour le marché)))
Sergey Dzyublik:
1. Un gardien, dont la conception est similaire au modèle utilisé pour stocker l'état lors de la saisie de contenu modifiable pour annuler les changements lorsque ces changements ne sont pas un mais plusieurs centaines. Par exemple un éditeur de photos, un éditeur de texte...
2. En fait, c'est une mauvaise pratique de ne pas connaître et de ne pas comprendre le sujet pour y critiquer quelque chose...
Le point clé a été mis en évidence. C'est le contenu modifiable qui est à l'origine de nombreux problèmes de mauvaise utilisation de la POO. Moi aussi, j'ai été dans cette situation pendant longtemps, mais avec l'expérience, on comprend progressivement. Le code où il y a beaucoup d'interrelations entre les objets (pointeurs) et en même temps ces objets sont modifiables - est une terrible nouille qui ne changera pas. Ainsi, nous devrions nous efforcer de rendre les objets de référence immuables. Seuls les objets de valeur doivent être modifiables, c'est-à-dire les structures et les types simples, ainsi que les pointeurs.
Dans ce cas, il est souhaitable de déclarer l'objet initial comme une structure, et non comme une classe. Ensuite, vous pouvez modifier son contenu. Dans ce cas, bien sûr, aucun pointeur vers cet objet ne sera pris et sauvegardé comme dans le pattern discuté, et c'est correct. Pour modifier les objets, vous devez vous référer explicitement à leurs méthodes, ou les passer comme argument à une fonction, c'est à dire
ou
Pas comme ça :
on a l'impression de modifier un objet souvenir, mais en fait on modifie un autre objet, qui est probablement situé ailleurs dans le programme. Cela crée un effet secondaire, ce qui revient à modifier une variable globale à un endroit et à utiliser sa valeur à un autre endroit.
C'est-à-dire qu'un mémento ne doit pas stocker une référence à l'objet original. Il ne doit stocker que le contenu. C'est mon opinion, mais je pense que je ne suis pas loin de la vérité).
Je ne revendique pas mon opinion, j'ai probablement lu quelque part, mais à mon avis, il n'y a que deux problèmes en programmation : la structure correcte du programme et trouver rapidement un bon nom pour une variable, et tout le reste se fait très facilement.
Je suis aussi sérieux.
Merci, je vais lire vos modèles
J'attendrai, au cas où quelqu'un d'autre apparaîtrait, mais seulement au niveau des questions des débutants et des formateurs ; les akademvelopers s'y engouffrent )))).
1) Le code, qui a beaucoup d'interrelations entre les objets (pointeurs), et en même temps les objets sont modifiables, est une nouille absurde, dans laquelle le diable ne peut pas comprendre plus tard. Par conséquent, il est nécessaire de s'efforcer pour queles objets de référence soient immuables.
2)Seulement les objets de valeur, c'est-à-dire les structures et les types simples, et les pointeurs devraient être modifiables.
3) Dans cecas, il est souhaitable de déclarer l'objet initial comme une structure, et non comme une classe. On peut alors modifier son contenu. Bien sûr, on ne peut pas prendre un pointeur sur cet objet et le sauvegarder comme dans le pattern discuté, et c'est correct.
4) Lesobjets doivent être modifiés en appelant explicitement leurs méthodes ou en les passant comme argument dans une fonction.
On a l'impression de modifier l'objet memento mais en fait il s'agit d'un autre objet qui se trouve probablement ailleurs dans le programme. Cela crée un effet secondaire.
1. Il s'avère que l'arbre de structure des données vient du mal...
2. pauvre C++ où class == private struct, que faire, nous devrions probablement abandonner les structures et les classes.
3. et c'est vrai : pas de motifs, pas de tri par pointeurs, pas d'économie de mémoire, surtout pour les gros objets...
4. N'oublions pas d'interdire l'utilisation des interfaces et des fonctions modèles, sinon vous ne comprendrez pas avec quel objet vous travaillez - quelle horreur...