Questions sur la POO dans MQL5 - page 49
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
Et le but de ces jeux d'esprit sauvages ? Le "but" (entre guillemets, parce que... gladiolus) du pattern est de"sans rompre l' encapsulation, fixer et préserver l'état interne de l'objet" (entre guillemets, parce que citation). Mais vous ne pouvez pas vous passer de la méthode setState(). Alors où est l'économie de l'encapsulation ici ? Pour écrire deux méthodes supplémentaires pour chaque champ privé... Ouais... cool, l'encapsulation est préservée.
Et soyez honnête, utiliserez-vous cette approche dans la pratique ? J'en doute. En pratique, vous le rendrez explicite et transparent - par exemple, une structure avec le même ensemble de champs et quelques méthodes de sauvegarde et de restauration. Et puis l'encapsulation sera vraiment préservée, il n'y aura que deux nouvelles méthodes : pour sauvegarder l'état et pour le restaurer.
OK, je vais le sauvegarder, j'avais besoin de tester le principe de travail, peut-être que c'est ce que je cherchais - un code pour le testeur et pour l'EA en fonctionnement, qui peut sauvegarder son état, et dans le testeur au contraire ne pas gaspiller de ressources sur des "gestes supplémentaires" - une partie de ce modèle peut être couverte par #ifdef -ami ;)
J'essaie de comprendre le sens de ce bachotage avec le gardien, mais je ne vois pas d'utilité particulière. En fait, c'est une mauvaise pratique de programmation par la création d'effets secondaires. Quand on change un objet, on en change un autre. Il est préférable de viser la pureté du code, à mon avis.
Qu'est-ce qui vous empêche de simplement copier un objet vers un autre objet, puis de le recopier ? C'est essentiellement la même chose, mais plus correct et plus clair.
Si ce singleton possède à la fois des setters et des getters (c'est-à-dire qu'il permet de changer son état et de le lire), cela équivaut à travailler avec des variables globales. Et tout programmeur sait que travailler en changeant l'état global est un mal. Mais le singleton ne compte pas).
J'essaie de comprendre le sens de cette histoire de dépositaire, mais je n'y vois pas d'avantage particulier. En fait, c'est une mauvaise pratique de programmation en créant des effets de bord. Quand on change un objet, on en change un autre. Il est préférable de viser la pureté du code, à mon avis.
C'est plus simple, j'apprends les trucs techniques.
J'ai l'habitude d'évaluer l'état d'un système automatisé du point de vue d'une machine à états finis, et je veux toujours garder un "instantané" de l'état du système comme réserve )))).
J'ai plus l'habitude d'évaluer l'état d'un système automatisé du point de vue d'une machine à états finis, et cela me pousse toujours à vouloir être en mesure de conserver un "moulage" de l'état du système comme sauvegarde ;)))
C'est juste qu'une telle mise en œuvre est excessivement compliquée et déroutante, à mon avis.
L'objectif est clair, c'est juste trop compliqué et confus, à mon avis.
Hélas, c'est ainsi que sont les gens - tant que je n'aurai pas reçu mes coups de pied au cul, il est peu probable que je l'obtienne)).
Hélas, les gens sont comme ça - jusqu'à ce que je reçoive mes propres coups et bosses, il est peu probable que je comprenne))).
Il n'y a rien de mal à ce que quelqu'un étudie ces schémas, c'est génial - c'est une gymnastique pour le cerveau, etc. etc. Et puis, en y regardant de plus près, il s'avère que c'est un trucage infernal, un mème pour éloigner les pigeons de la réalité, tout comme apprendre le BASIC visuel en écrivant des applications console.
L'étude de ces modèles est intéressante, ne serait-ce que du point de vue de l'apprentissage des cafards de quelqu'un - ce qu'ils sont dans la nature.
Et si l'on s'approche vraiment de la tâche de préserver l'état d'un objet, le moyen est de rendre possible la copie d'un objet sur un autre, à sa guise, que ce soit une simple méthode ou une surcharge = overloading. Et après cela, vous ne voudrez peut-être pas encapsuler cette fonctionnalité.
Et si l'on aborde vraiment la tâche de préserver l'état d'un objet, la façon de le faire est de rendre possible la copie d'un objet sur un autre, comme on le souhaite, que ce soit simplement par une méthode ou par une surcharge =. Et après cela, vous ne voudrez peut-être pas encapsuler cette fonctionnalité.
En réalité, tout système technique peut être conçu sur la base de 3 principes de base :
- est conforme à la dernière norme
- nos grands-pères l'ont construit de cette façon, pas besoin de réinventer la roue
- Vous ne devriez pas le construire avec de la merde et des bouts de bois, puis le modifier.
)))
Je plaisante, j'ai le temps de lire et de jouer avec les options dans ma tête, j'en profite, ainsi que de l'opportunité d'obtenir des explications rapides pour les points peu clairs sur le forum ;)
J'essaie de comprendre le sens de cette histoire de dépositaire, mais je n'y vois pas d'avantage particulier. En fait, c'est une mauvaise pratique de programmation en créant des effets de bord. Quand on change un objet, on en change un autre. Il est préférable de viser la pureté du code, à mon avis.
Qu'est-ce qui vous empêche de simplement copier un objet dans un autre objet, puis de le recopier ? C'est pratiquement la même chose, mais plus correct et plus clair.
Si ce singleton possède à la fois des setters et des getters (c'est-à-dire qu'il permet de changer son état et de le lire), cela équivaut à manipuler des variables globales. Et tout programmeur sait que travailler en changeant l'état global est un mal. Mais le singleton ne compte pas).
Je suppose que c'est le point de vue typique d'un programmeur qui n'a jamais eu à s'occuper de projets sérieux à grande échelle... Pardonnez-moi d'être franc, mais je ne vois pas d'autre explication pour qualifier les bases de mauvaises pratiques ;).
Il n'y a rien de mal à ce que quelqu'un étudie ces modèles, c'est génial - des exercices cérébraux, etc. etc. Et puis, en y regardant de plus près, il s'avère qu'il s'agit d'une sorte de faux infernal, d'une sorte de mème pour attirer les pigeons loin de la réalité, tout comme apprendre le BASIC visuel en écrivant des applications de console.
L'étude de ces schémas est intéressante, ne serait-ce que du point de vue de l'apprentissage des cafards de quelqu'un - ce qu'ils sont dans la nature.
Et si l'on s'approche vraiment de la tâche de préserver l'état d'un objet, le moyen est de rendre possible la copie d'un objet sur un autre, à sa guise, que ce soit une simple méthode ou une surcharge = overloading. Et au-delà, peut-être que le désir d'encapsuler cette fonctionnalité disparaîtra.
Dmitry, probablement dans ce cas vous confondez un peu les tâches des modèles Keeper et Prototype, et toutes leurs combinaisons et manifestations possibles. Le premier instantané 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 de ces tâches ici, c'est exagéré, bien sûr).
1) J'essaie de comprendre l'intérêt de cette histoire de gardien, mais je n'en vois pas l'utilité.
2) C'est essentiellement une mauvaise pratique de programmation que de créer des effets secondaires.
3) Quand on change un objet, on en change un autre. En conséquence, le code s'emmêle et devient difficile à comprendre. Il est toujours préférable de rechercher la pureté du code, à mon avis.
4) Qu'est-ce qui vous empêche de simplement copier un objet dans un autre objet, puis de le recopier ? En fait, c'est la même chose, mais de façon plus correcte et plus claire.
Si ce singleton possède à la fois des setters et des getters (c'est-à-dire qu'il permet de changer son état et de le lire), cela équivaut à travailler avec des variables globales. Tout programmeur sait que travailler en changeant l'état global est un mal. Mais le singleton ne compte pas).
Ne faites-vous pas partie de la secte "ils l'installent, nous n'en avons pas besoin, c'est à vous..." ? ? ??
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...