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

Nouveau commentaire
 

BTW, savez-vous que la version 1325 a introduit les pointeurs dans les fonctions?
Cela fait-il une différence dans l'application de la communication triangulaire ?

MQL5 : Ajout de la prise en charge des pointeurs vers les fonctions pour simplifier l'organisation des modèles d'événements.

Pour déclarer un pointeur vers une fonction, il faut spécifier le type "pointeur vers une fonction", par exemple :

typedef int (*TFunc)(int,int);

Maintenant, TFunc est un type, et il est possible de déclarer la variable pointeur vers la fonction :

TFunc func_ptr;

La variable func_ptr peut stocker l'adresse de la fonction pour la déclarer plus tard :

int sub(int x,int y) { return(x-y); }
int add(int x,int y) { return(x+y); }
int neg(int x)       { return(~x);  }

func_ptr=sub;
Print(func_ptr(10,5));

func_ptr=add;
Print(func_ptr(10,5));

func_ptr=neg;           // error: neg is not of  int (int,int) type
Print(func_ptr(10));    // error: there should be two parameters

Les pointeurs vers les fonctions peuvent être stockés et passés comme paramètres. On ne peut pas obtenir un pointeur sur une méthode de classe non statique.

 
Je ne suis pas sûr que l'utilisation des pointeurs de fonction soit également mise en œuvre dans MT4. Si c'est le cas, il est bien sûr possible de procéder de cette manière, à condition que ces pointeurs puissent également être gérés par des tableaux, car cela est possible avec les pointeurs de classe.
 

probablement juste pour MT5, et d'après ce que j'ai vu, ce n'est toujours pas pour les méthodes, juste pour les fonctions.

De toute façon, je ne comprends toujours pas comment définir la capacité d'un tiers dans la classe de base, par exemple dans le contexte de la ligne de tendance et du conteneur, où est le troisième objet.

Mais je vais essayer de relire.

 
Ce qui me semble manquer dans la compréhension du modèle d'événements en conjonction avec OO et MQL5, c'est le bon type de répartition des événements.
Je veux dire, comment et où décider qui (quelle classe) va recevoir quoi (événement).
Il est clair que le distributeur principal, celui qui est natif du langage, c'est-à-dire le langage ::OnChartEvent, n'est écrit qu'une seule fois dans un projet, dans la classe de niveau supérieur.

À partir de là, quelle est la ou les bonnes façons de distribuer des événements à différents objets ?
Doit-il y avoir une classe d'événement de distribution ? Faut-il le faire uniquement dans le ::OnChartEvent sur la base d'instructions if ?
 
OK, je crois que j'ai compris. Il y a un réel problème de changement de concept lorsque vous passez du procédural à l'opérationnel.
Si j'ai bien compris, ce que vous voulez dire, c'est qu'il faut que la CTrendLine informe de son croisement de prix un objet hérité de CTrade au moyen d'un événement, sans avoir à connaître l'existence de CTrade, n'est-ce pas ?
 
Amir Yacoby:
Ce qui me semble manquer dans la compréhension du modèle d'événements en conjonction avec OO et MQL5, c'est le bon type de répartition des événements.
Je veux dire, comment et où décider qui (quelle classe) va recevoir quoi (événement).
Il est clair que le distributeur principal, celui qui est natif du langage, c'est-à-dire le langage ::OnChartEvent, n'est écrit qu'une seule fois dans un projet, dans la classe de niveau supérieur.

À partir de là, quelle est la ou les bonnes manières de distribuer des événements à différents objets ?
Doit-il y avoir une classe d'événement de distribution ? Doit-on le faire uniquement dans le ::OnChartEvent sur la base d'instructions if ?
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.
 
Amir Yacoby:
OK, je crois que j'ai compris. Il y a un vrai problème de changement de concept quand on passe du procédural à l'oop.
Si j'ai bien compris, ce que vous voulez dire, c'est qu'il faut que la CTrendLine informe de son croisement de prix un objet hérité de CTrade au moyen d'un événement, sans avoir à connaître l'existence de CTrade, n'est-ce pas ?
Je prétends que oui.
 
Donc, en fait, chaque objet a maintenant une place pour un objet qui est le récepteur d'événements, et a également une méthode d'enregistrement pour l'objet d'écoute pour s'abonner en tant que tel et une méthode d'envoi d'événement et une méthode de gestion d'événement utilisée par le récepteur.

C'est bien, cela me rappelle le modèle de l'observateur, sauf que l'observateur a plus d'un destinataire possible, le m_reciever est un tableau d'objets.

En fait, j'ai voulu une fois implémenter l'observateur et à cause du manque d'interfaces dans MQL ou de l'héritage multiple, je ne l'ai pas fait. Je n'ai pas pensé à votre bonne idée selon laquelle le même objet peut forcer l'interface des deux côtés.


 
Amir Yacoby:
Donc, en fait, chaque objet a maintenant une place pour un objet qui est le récepteur d'événements, et a également une méthode d'enregistrement pour l'objet d'écoute pour s'abonner en tant que tel et une méthode d'envoi d'événement et une méthode de gestion d'événement utilisée par le récepteur.

C'est bien, cela me rappelle le modèle de l'observateur, sauf que l'observateur a plus d'un destinataire possible, le m_reciever est un tableau d'objets.

En fait, j'ai voulu une fois implémenter l'observateur et à cause du manque d'interfaces dans MQL ou de l'héritage multiple, je ne l'ai pas fait. Je n'ai pas pensé à votre bonne idée selon laquelle le même objet peut forcer l'interface des deux côtés.


Juste pour vous encourager, j'ai beaucoup utilisé les listeners avec MQL4.
 
Ovo Cz:
Juste pour vous encourager, j'ai beaucoup utilisé les listeners avec MQL4.

Merci, mais je ne me sens pas encouragé ( :

J'ai réussi à le faire, mais pas avec un contrat entre l'éditeur et le listener, je veux dire, l'éditeur devait supposer que le listener a la méthode de manipulation, mais rien ne l'obligeait à le faire.
Ou alors, il faudrait que j'hérite de tous les listeners d'un objet listener principal - mais alors, bien sûr, je perdrais tout intérêt car ils ne peuvent pas hériter d'autres classes.

Quoi qu'il en soit, je suis un pro de la programmation mais certainement pas de l'OO où je manque d'expérience pour l'instant, et je ne suis pas en compétition avec l'un de vous, programmeurs OO expérimentés comme Doerk.
Ce que j'ai appris, c'est qu'être procédural vous donne une bonne logique et de bonnes compétences en programmation, mais le changement est mentalement difficile, surtout si un orienté procédural comme moi est confronté à la mission de construire un cadre OO, c'est un état d'esprit totalement différent. Et le framework de la partie GUI est le framework le plus détaillé avec de nombreux événements à prendre en charge, je pense que vous serez d'accord pour dire que parmi les frameworks, c'est le plus difficile à construire.

12345
Nouveau commentaire