Comment créer des objets de manière dynamique ? (Quelques trucs de POO) - page 4

 

Absolument. Il m'a fallu des mois pour créer mon propre framework GUI avec MQL, sans compter l'expérience que j'avais déjà dans le passé en créant des bibliothèques comme celles-ci. La partie la plus difficile n'est pas les événements, c'est plus l'architecture et la quasi impossibilité de déboguer le code, à cause de toutes les imbrications et récursions mais aussi à cause des états de la souris qui deviennent déjà invalides quand le débogage commence.

A propos, j'ai proposé une collaboration à MQ avec ces librairies il y a des mois et malheureusement je n'ai même pas eu de réponse. Mais le fait est que la bibliothèque de contrôle standard est juste un bel essai, mais aussi un mauvais essai par rapport à ce qui est réellement possible. On peut faire beaucoup mieux. Peut-être que je devrais proposer la bibliothèque sur le marché ici, mais j'ai peur du travail que cela représente d'écrire toute la documentation pour elle.

 
Doerk Hilger:
Ce n'est pas du tout une question. La POO est basée sur les principes de la nature. La terre ne vous nourrit pas, elle fournit juste les ressources et c'est à vous de décider si, quand et où vous en avez besoin.
Pouvez-vous dire ce que vous entendez par là ? J'ai l'impression générale de ce que vous dites, mais ce n'est pas très clair.
Vous voulez dire que lors de la création d'un cadre, il suffit de s'occuper de fournir les ressources ? J'ai compris cela, mais j'ai du mal à le mettre en pratique car ma tendance est trop forte.

Par exemple, si je crée un cadre et que je crée le bouton et le bouton radio, qui est une sorte de conteneur de bouton, lorsque je crée le bouton radio, ma tendance est de penser à l'objet dépendant, le bouton dans ce cas, et à la façon dont je communique avec lui. C'est une habitude de programmation procédurale, je me demande si vous avez fait le changement dans votre passé de la programmation procédurale à l'OO et si vous pouvez m'indiquer une vue claire de ce sur quoi je dois me concentrer dans ce cas. Parce que j'ai tendance à me concentrer davantage sur le bouton (objet dépendant) que sur le bouton radio.

Je ne suis pas sûr d'avoir été clair, c'est juste une question sur les points importants sur lesquels il faut se concentrer lors de la création d'un niveau dans un framework.
 
Amir Yacoby:
Pouvez-vous dire ce que vous entendez par là ? J'ai l'impression générale de ce que vous dites, mais ce n'est pas très clair.
Vous voulez dire que lors de la création d'un cadre, il suffit de fournir les ressources ? J'ai compris cela, mais j'ai du mal à le mettre en pratique car ma tendance est trop forte.

Par exemple, si je crée un cadre et que je crée le bouton et le bouton radio, qui est une sorte de conteneur de bouton, lorsque je crée le bouton radio, j'ai tendance à penser à l'objet dépendant, le bouton dans ce cas, et à la façon dont je communique avec lui. C'est une habitude de programmation procédurale. Je me demande si vous n'avez pas fait le passage de la programmation procédurale à la programmation ouverte et si vous ne pouvez pas m'indiquer une vue claire de ce sur quoi je dois me concentrer dans ce cas. Parce que j'ai tendance à me concentrer davantage sur le bouton (objet dépendant) que sur le bouton radio.

Je ne suis pas sûr d'avoir été clair, c'est juste une question sur les points importants sur lesquels il faut se concentrer lors de la création d'un niveau dans un framework.

Peut-être que je n'ai pas compris, mais je voudrais vous donner mon opinion.

Je pense que vous êtes trop sur la "théorie", et que vous attendez la lumière de quelqu'un d'autre. Il n'y a pas de solution parfaite, il y a des solutions et vous devez les trouver à partir de votre expérience et de vos besoins concrets.

Ce sujet est parti d'un cas pratique, et il est devenu une discussion obscure sur la POO. Il y a une série d'articles intéressants sur les interfaces graphiques, vous devriez y jeter un coup d'oeil, puis essayer de construire une interface en utilisant la bibliothèque standard, et en utilisant la bibliothèque de ces articles, et étudier le code...ou pas.

C'est juste une suggestion, car je ne vois vraiment pas comment on pourrait vous aider beaucoup mieux.

Graphical Interfaces I: Preparation of the Library Structure (Chapter 1)
Graphical Interfaces I: Preparation of the Library Structure (Chapter 1)
  • 2016.02.01
  • Anatoli Kazharski
  • www.mql5.com
This article is the beginning of another series concerning development of graphical interfaces. Currently, there is not a single code library that would allow quick and easy creation of high quality graphical interfaces within MQL applications. By that, I mean the graphical interfaces that we are used to in familiar operating systems.
 
Alain Verleyen:

Peut-être que je n'ai pas compris, mais je voudrais vous donner mon opinion.

Je pense que vous êtes trop sur la "théorie", et que vous attendez la lumière de quelqu'un d'autre. Il n'y a pas de solution parfaite, il y a des solutions et vous devez les trouver à partir de votre expérience et de vos besoins concrets.

Ce sujet est parti d'un cas pratique, et il est devenu une discussion obscure sur la POO. Il y a une série d'articles intéressants sur les interfaces graphiques, vous devriez y jeter un coup d'oeil, puis essayer de construire une interface en utilisant la bibliothèque standard, et en utilisant la bibliothèque de ces articles, et étudier le code...ou pas.

C'est juste une suggestion, car je ne vois vraiment pas comment on pourrait vous aider beaucoup mieux.

Alain, j'ai construit une interface et j'ai lu les articles.
Ce n'est peut-être pas l'endroit pour discuter d'OO, tu as peut-être raison.
J'ai commencé à en discuter parce que Doerk a présenté le sujet comme réponse au sujet débutant et a parlé de l'approche OO correcte.
Le sujet beginner lui-même était intéressé par la présentation OO de Doerk, et je pense qu'il est naturel d'en discuter ici.
Vous avez peut-être raison de dire que c'est trop théorique, mais je pense quand même qu'une approche OO correcte ne peut pas se passer d'une certaine théorie et qu'à la fin, elle devient pratique.

Ma difficulté est la pensée correcte OO, je me demandais juste si par hasard Doerk pourrait connaître de son expérience la difficulté mentale que j'ai présentée.

 
Alain Verleyen:

Il y a une série d'articles intéressants sur les interfaces graphiques, vous devriez y jeter un coup d'oeil, puis essayer de construire une interface en utilisant la bibliothèque standard, et en utilisant la bibliothèque de ces articles, et étudier le code...ou pas.


Je viens de le télécharger pour voir ce qu'il fait. Et la première impression montre, qu'ils ont fait les mêmes mauvaises erreurs qu'avec la bibliothèque de contrôle standard. Déjà le tout premier exemple avec une seule fenêtre de dialogue fait passer l'utilisation du CPU de 10% (sans) à 50-65% (chargé). C'est déjà la meilleure preuve que les auteurs n'ont pas l'expérience nécessaire pour développer une telle bibliothèque et que cela ne peut pas être - une - façon de faire les choses correctement.

De toute façon, je ne comprends pas pourquoi MQ ne fournit pas un cadre professionnel d'interface graphique au lieu d'expliquer comment c'est (pas) fait. La plupart des programmeurs MQL veulent sûrement développer des EAs et des Indicateurs, mais ne veulent pas s'embêter avec ce genre de choses.

De plus, le panel de leur exemple est mort dans le testeur de stratégie, et c'est là que tous ces trucs GUI deviennent absurdes de toute façon. Ce n'est pas une critique contre vous ou contre ce que vous avez écrit, je sais moi-même qu'il n'y a tout simplement pas de meilleur matériel public disponible pour MQL ici.

 
Amir Yacoby:

Alain, j'ai construit une interface et j'ai lu les articles.
Peut-être que ce n'est pas l'endroit pour discuter de la POO, tu as peut-être raison.
J'ai commencé à en discuter parce que Doerk a présenté le sujet comme réponse au sujet débutant et a parlé de l'approche OO correcte.
Le sujet beginner lui-même était intéressé par la présentation OO de Doerk, et je pense qu'il est naturel d'en discuter ici.
Bien que vous ayez peut-être raison de dire que c'est trop théorique, je pense néanmoins qu'une approche OO correcte ne peut se faire sans impliquer une certaine théorie et qu'à la fin, elle devient pratique.

Ma difficulté est la pensée correcte OO, je me demandais juste si par hasard Doerk pourrait connaître de son expérience la difficulté mentale que j'ai présentée.

Il n'y a aucun problème à discuter de la POO ici.

Je ne suis pas d'accord avec votre "OO ne peut pas sans impliquer une certaine théorie", mais cela n'a pas d'importance.

 
Alain Verleyen:

Il n'y a aucun problème à discuter de la POO ici.

Je ne suis pas d'accord avec votre "OO ne peut pas sans impliquer une théorie", mais cela n'a pas d'importance.

Dans ce cas, comment expliquez-vous le fait qu'il existe une mauvaise programmation OOP ? Jetez juste un coup d'oeil à la tentative de solution OO des initiateurs du sujet et à la réponse de Doerks. Il doit y avoir une théorie qui fait la différence entre le bien et le mal, n'est-ce pas ?
 
Doerk Hilger:

Je viens de le télécharger pour voir ce qu'il fait. Et la première impression montre qu'ils ont fait les mêmes mauvaises erreurs qu'avec la bibliothèque de contrôle standard. Déjà le tout premier exemple avec une seule fenêtre de dialogue fait passer l'utilisation du CPU de 10% (sans) à 50-65% (chargé). C'est déjà la meilleure preuve que les auteurs n'ont pas l'expérience nécessaire pour développer une telle bibliothèque et que cela ne peut pas être - une - façon de faire les choses correctement.

De toute façon, je ne comprends pas pourquoi MQ ne fournit pas un cadre professionnel d'interface graphique au lieu d'expliquer comment c'est (pas) fait. La plupart des programmeurs MQL veulent sûrement développer des EAs et des Indicateurs, mais ne veulent pas s'embêter avec ce genre de choses.

De plus, le panel de leur exemple est mort dans le testeur de stratégie, et c'est là que tous ces trucs GUI deviennent absurdes de toute façon. Ce n'est pas une critique contre vous ou contre ce que vous avez écrit, je sais moi-même qu'il n'y a tout simplement pas de meilleur matériel public disponible pour MQL ici.

Doerk, vous avez très probablement raison, mais ce n'est pas ce que je veux dire.

Vous devriez écrire un exemple concret expliquant pourquoi ce problème de CPU se produit, expliquer à Anatoli (auteur des articles) quel est le problème. Je suis désolé de dire que, jusqu'à présent, tout ce que vous avez dit est presque inutile, même si vous avez 100% raison. C'est juste trop général et théorique. Sans vouloir vous offenser.

 
Le problème est que cette question est beaucoup trop complexe pour donner des instructions exactes. C'est pourquoi j'essaie de donner quelques idées et des pistes à ceux qui sont intéressés. Malheureusement, je n'ai pas le temps d'écrire un article ni de publier une bibliothèque entièrement documentée. Désolé.
 
Doerk Hilger:
Le problème est que cette question est beaucoup trop complexe pour donner des instructions exactes. C'est pourquoi j'essaie de donner quelques idées et des pistes à ceux qui sont intéressés. Malheureusement, je n'ai pas le temps d'écrire un article ni de publier une bibliothèque entièrement documentée. Je suis désolé.
Shxxxx. Vous avez compris