Questions sur la POO dans MQL5 - page 55
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
Tu es coincé dans les détails. Inintéressant. Le point principal de la discussion sur le modèle "keeper" ici était qu'il promet en quelque sorte la préservation de l'encapsulation, mais qu'il est mis en œuvre en créant un couple de méthodes publiques pour chaque champ. C'est drôle que tu n'aies pas compris le message le plus important.
Je ne suis pas coincé, j'essaie, par respect pour votre interlocuteur, de donner un sens à vos propos et de démêler vos auto-contradictions. Apparemment en vain.
Je ne pense pas non plus que quiconque ici soit intéressé par votre écume de "modèles sacrés".
Tout ici est clair, spécifique et canonique. Il y a un LIVRE ! Ce livre expose ces modèles, et c'est de cela qu'il s'agit. Le livre s'appelle Design Patterns ou quelque chose comme ça. Mais pas seulement le livre, il y a beaucoup de sites à leur sujet sur Internet et même dans Wikipedia, l'essentiel est que le sujet soit canonisé)) ...et celui qui ne comprend pas les design patterns - plébéien, et qui les maîtrise - il a maîtrisé la vie elle-même ! Amen !
Vous êtes comme un clown, hélas. Quittez simplement le fil de discussion OOP, si cela vous dégoûte tant).
Tout ici est clair, spécifique et canonique. Il y a un LIVRE ! Ce livre expose ces modèles, et c'est de cela qu'il s'agit. Le livre s'appelle Design Patterns ou quelque chose comme ça. Mais il n'y a pas que le livre, il y a beaucoup de sites web sur eux sur Internet et même dans wikipedia, l'essentiel est que le sujet soit canonisé)).
Bien sûr, s'il y a jusqu'à 100 variables globales, on peut se passer de fonctions, s'il y a plus de 50 EA, alors les classes sont appropriées, et je comprends bien, s'il y a plus de 20 développeurs et plus de 20 méthodes et que le nombre de variables est inconnu, alors le pattern est nécessaire. S'il n'y a qu'un seul développeur, alors si oui, pas tant que ça ?
Je ne suis pas coincé, j'essaie, par respect pour votre interlocuteur, de donner un sens à vos propos et de démêler vos auto-contradictions. Apparemment pour rien.
Je ne pense pas non plus que quiconque ici soit intéressé par votre écume de "modèles sacrés".
Je n'ai pas de contradictions, la contradiction est dans vos patterns, j'ai déjà écrit deux fois à leur sujet, laissez-moi vous rappeler : un pattern "keeper" promet la préservation de l'encapsulation mais est implémenté en créant deux méthodes publiques pour chaque champ privé.
Et dites-moi, où avez-vous vu une contradiction dans mon schéma ?
Bien sûr, s'il y a jusqu'à 100 variables globales, alors on peut se passer des fonctions, s'il y a plus de 50 EA, alors les classes sont appropriées, et je comprends bien, s'il y a plus de 20 développeurs, plus de 20 méthodes et que le nombre de variables est inconnu, alors le pattern est nécessaire. S'il n'y a qu'un seul développeur, alors, si oui, pas tant que ça ?
Les développeurs ont besoin de cerveaux en premier lieu.
Vous êtes comme un clown, hélas. Quittez simplement le fil de discussion OOP si vous êtes si dégoûté par ce sujet).
Quoi "ça" ? J'aime bien OOP. Mais ces modèles notoires n'ont qu'un rapport lointain avec la vraie POO.
Je n'ai pas de contradiction, la contradiction est dans vos schémas, j'en ai déjà parlé deux fois, rappel : le schéma "keeper" promet de préserver l'encapsulation, mais il est mis en œuvre en créant deux méthodes publiques par champ privé.
Je comprends maintenant. Tu as juste déversé de l'émotion contre tous les modèles, que le sens de tes mots a été perdu.
Mais dans Snapshot, ce problème est résolu en utilisant des classes imbriquées pour Snapshot.
Si ce n'est pas supporté par le langage, je suis d'accord, il y a cet inconvénient, mais il peut être contourné par quelques astuces de béquille dont je me souviens.
Je comprends maintenant. Tu as juste édulcoré l'émotion contre tous les schémas, que le sens de tes mots a été perdu.
Mais dans Snapshot, ce problème est résolu en utilisant des classes imbriquées pour Snapshot.
Si ce n'est pas supporté par le langage, je suis d'accord, cet inconvénient est présent, mais il peut être contourné avec quelques astuces de béquille, je me souviens.
Vous avez tout faux.
Peu importe qu'il soit possible d'écrire une classe imbriquée ou non, ce n'est pas une grande différence. Il y a un exemple de code dans ce fil de discussion avec une classe imbriquée et deux méthodes publiques par champ privé.
Quoi "ça" ? J'aime bien OOP. Mais ces modèles notoires n'ont qu'un rapport assez lointain avec la véritable POO.
Je vais le répéter - personne ne prie sur les modèles. Il s'agit simplement de modèles qui peuvent être utilisés comme référence.
Mais affirmer qu'ils n'ont rien à voir avec la POO, eh bien, ce n'est pas vrai.
D'après mon humble expérience, sous forme de livre pur, ils sont rarement utilisés, à de rares exceptions près. En général, si une tâche convient à un modèle, elle va de pair avec au moins deux autres tâches pour d'autres modèles, et c'est ainsi que l'on peut croiser 2-3-10+ modèles, ce qui est un travail pour le cerveau du programmeur/architecte.
Vous ne comprenez rien.
Que vous puissiez ou non écrire une classe imbriquée n'est pas pertinent, ce n'est pas une grande différence. Dans ce fil de discussion, il y a un exemple de code avec une classe imbriquée et deux méthodes publiques par champ privé.
Tu m'as déjà dit tellement de fois que je suis un idiot et que je ne comprends rien, je suis fier de mon sang-froid pour ne pas t'avoir envoyé un fuck off bien mérité il y a longtemps).
Fondamentalement, une classe imbriquée rend facultatives les méthodes publiques pour les champs privés, c'est la violation de l'encapsulation dont vous parlez. D'autres arguments ?