Parler de l'OLP dans le salon - page 7
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
ZS : au fait, je n'ai pas vu un seul souhait de couverture d'un quelconque sujet dans tout le fil de discussion, comme d'habitude, les querelles habituelles.
A en juger par le choix de l'exemple initial, on peut raisonnablement douter de la qualité de la couverture
Peut-on être plus précis sur qui ils sont et ce qu'ils n'ont pas appris? Les modérateurs n'ont pas appris à nettoyer ou autre chose).
ZS : d'ailleurs, dans tout le fil de discussion, je n'ai pas vu un seul souhait de couvrir un quelconque sujet, comme toujours, la rancœur habituelle. J'ai donc décidé d'enregistrer des vidéos sur YouTube en partant de zéro sur le fonctionnement de la POO, au moins cela aura une certaine utilité. De toute façon, dans quelque temps, la branche se retrouvera dans le branch_sucker.
Laissez-moi être plus précis : ils n'ont pas appris à utiliser la POO.
Alexey, je pense que vous êtes bien conscient de vous-même que vous ne pouvez pas simplement apprendre la POO. Il existe une connaissance formelle de la POO : héritage, encapsulation, polymorphisme - tous ces mantras sont souvent répétés, mais il y a plus de mal que de bien à ce que quelqu'un les mémorise et les applique de manière violente et inappropriée, comme par exemple une classe Expert pour hériter d'un module MM (bonjour aux développeurs SB :).
Quant à MQL, c'est un langage très faible en termes de POO: le contrôle des types est complètement absent (au moins, ils ont implémenté le safe casting), la réflexion en est à ses débuts et est très limitée, il n'y a pas du tout d'interfaces. La question se pose : quel type de POO peut être enseigné dans MQL ? Que dire, si les développeurs eux-mêmes moulent une chose si laide dans la bibliothèque standard, que parfois c'est juste effrayant.
Pour être plus précis : nous n'avons pas appris la POO.
Alexey, je pense que vous êtes bien conscient du fait que vous ne pouvez pas simplement apprendre la POO. Il existe une connaissance formelle de la POO : héritage, encapsulation, polymorphisme - tous ces mantras sont souvent répétés, mais il y a plus de mal que de bien à ce que quelqu'un les mémorise et les applique de manière violente et inappropriée, comme par exemple une classe Expert pour hériter d'un module MM (salut aux développeurs SB :).
Quant à MQL, c'est un langage très faible en termes de POO: le contrôle des types est complètement absent (au moins, ils ont implémenté le safe casting), la réflexion en est à ses débuts et est très limitée, il n'y a pas du tout d'interfaces. La question se pose : quel type de POO peut être enseigné dans MQL ? Que dire, si les développeurs eux-mêmes moulent une telle bosse dans la bibliothèque standard que parfois c'est juste effrayant.
Oui, c'est faible, mais des projets de gravité moyenne peuvent encore être réalisés. Le SB a été réalisé par différentes personnes ayant des niveaux de formation différents. Et il manque l'essentiel, j'utilise toujours votre CDictionary, et c'est le mât de la chose due.
Alors, quoi maintenant, s'allonger et mourir ? )) Vous allez peut-être vous lancer dans le dll après tout.
Vous pouvez apprendre la POO, je pense. Je l'ai appris moi-même. Et d'autres l'ont fait aussi.
Et vous pouvez toujours apprendre la POO, je pense. Je l'ai appris moi-même. Et d'autres aussi.
Il faut donc apprendre à partir des bons exemples. Mais il n'y en a pas en SB. Prenons l'exemple de CObject : il ne fournit pas de contrôle de type, il ne fournit pas de travail au niveau de l'interface avec les objets, mais il contient des méthodes sans signification comme Save() et Load() qui ne sont jamais redéfinies en pratique. Les pointeurs m_prev et m_next sont utilisés dans une seule classe CList, mais sont présents comme ballast pour toutes ses classes descendantes. La plus utile est la méthode Comparer(). En fait, elle est le plus souvent remplacée. Mais dans le bon sens du terme, Comparer() est une interface, elle ne devrait pas être définie dans le CObject, mais comme une classe séparée.
Apparemment, static et const (ce n'est pas de la POO) ne sont pas nécessaires.
En ce qui concerne la POO, il est très intéressant de savoir à quoi ressemblerait la fonction suivante, qui a une large application pratique (pas du tout abstraite), dans un style procédural ?
Évidemment, toute POO peut être réécrite en style procédural. Mais c'est la pratique qui m'intéresse. J'ai donc pris le petit code ci-dessus, où la POO est également utilisée au minimum.
Alors, à quel point le style procédural est-il plus agréable/plus pratique/plus lisible/plus correct que la POO dans cet exemple ? Eh bien, pas pour parler pendant quelques pages, mais juste pour comparer le code source court procédural contre OOP. Je demande aux adversaires d'OOP de montrer un cours magistral. Il ne s'agit pas du redoutable MT5, mais du bon vieux MT4.
Comment apprendre à programmer de la même manière ? :) c'est très joli.
Ou peut-être avez-vous besoin de changer votre état d'esprit.
par exemple, je ne savais pas que les structures peuvent être utilisées presque de la même manière que les classes, avec un constructeur
par exemple, je ne savais pas que les structures peuvent être utilisées presque de la même manière que les classes, avec un constructeur
quels moules peut-on apprendre à programmer exactement de la même manière ? :) c'est très joli
ou peut-être que vous devez aussi changer votre état d'esprit.
par exemple, je ne savais pas que les structures peuvent être utilisées presque comme des classes, avec un constructeur
Et puis-je demander : quel génie voyez-vous dans le code de fxsaber ? Peut-être est-ce les effets secondaires de IsChange qui vous ont captivé, ou l'idée que l'état du système doit être dupliqué au niveau de l'utilisateur ?
Puis-je demander : quel génie voyez-vous dans les codes de fxsaber ? Peut-être que ce sont les effets secondaires de IsChange qui vous fascinent, ou l'idée que l'état du système devrait être dupliqué au niveau de l'utilisateur ?
Probablement parce que je comprends à peine ce code :)
Désolé, je suis un programmeur amateur... Je ne suis familier avec la POO qu'à un niveau de base.
En C++, la classe et la structure sont les mêmes, seuls certains paramètres par défaut sont différents.
C'est cool, je ne savais pas ça... Je suppose que je dois juste apprendre à mieux connaître les pros.
Il faut donc apprendre à partir des bons exemples. Et il n'y en a pas à SB. Prenez CObject par exemple : il ne fournit pas de contrôle de type, il ne fournit pas de travail au niveau de l'interface avec les objets, mais il contient des méthodes insignifiantes comme Save() et Load(), qui ne sont jamais surchargées en pratique. Les pointeurs m_prev et m_next sont utilisés dans une seule classe CList, mais sont présents comme ballast pour toutes ses classes descendantes. La plus utile est la méthode Comparer(). En fait, elle est le plus souvent remplacée. Mais dans le bon sens du terme, Comparer() est une interface, elle ne devrait pas être définie dans le CObject, mais comme une classe séparée.