Wie kann man Objekte dynamisch erstellen? (Einige OOP-Sachen) - Seite 3

Neuer Kommentar
 

BTW, sind Sie sich bewusst, dass Build 1325 Zeiger auf Funktionen eingeführt hat?
Macht das einen Unterschied bei der Anwendung der Dreieckskommunikation?

MQL5: Unterstützung von Zeigern auf Funktionen wurde hinzugefügt, um die Anordnung von Ereignismodellen zu vereinfachen.

Um einen Zeiger auf eine Funktion zu deklarieren, geben Sie z.B. den Typ "Zeiger auf eine Funktion" an:

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

Jetzt ist TFunc ein Typ, und es ist möglich, die Variable Zeiger auf die Funktion zu deklarieren:

TFunc func_ptr;

Die Variable func_ptr kann die Adresse der Funktion speichern, um sie später zu deklarieren:

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

Zeiger auf Funktionen können gespeichert und als Parameter übergeben werden. Sie können keinen Zeiger auf eine nicht-statische Klassenmethode erhalten.

 
Ich bin mir nicht sicher, ob die Verwendung von Funktionszeigern auch in MT4 implementiert ist. Wenn ja, kann man das natürlich auch so machen, solange solche Zeiger auch über Arrays verwaltet werden können, denn das ist mit Klassenzeigern möglich.
 

ist wahrscheinlich nur für MT5, und von dem, was ich gesehen habe, ist es immer noch nicht für Methoden, nur Funktionen.

Jedenfalls verstehe ich immer noch nicht, wie Sie die Drittanbieter-Fähigkeit innerhalb der Basisklasse zu definieren, zum Beispiel im Zusammenhang mit Trendlinie und Container, wo ist das dritte Objekt.

Aber ich werde versuchen, wieder zu lesen.

 
Was mir im Verständnis des Ereignismodells in Verbindung mit OO und MQL5 zu fehlen scheint, ist die Frage, was die richtige Art des Dispatchings der Ereignisse ist.
Ich meine, wie und wo man entscheidet, wer (welche Klasse) was (Ereignis) bekommt.
Es ist klar, dass der oberste Dispatcher, der sprachliche, d.h. der sprachliche ::OnChartEvent nur einmal in einem Projekt geschrieben wird, in der obersten Klasse.

Was ist dann von hier aus der richtige Weg oder die richtigen Wege, um Ereignisse an verschiedene Objekte zu verteilen?
Sollte es eine Ereignisverteilungsklasse geben? Sollte es nur in der ::OnChartEvent auf der Grundlage von if-Anweisungen erfolgen?
 
OK, ich glaube, ich habe es verstanden. Es gibt ein echtes Problem der Konzeptverschiebung, wenn man von prozedural zu oop kommt.
Wenn ich Sie richtig verstanden habe, dann ist das, was Sie meinen, eine Möglichkeit für die CTrendLine, ihr Preiskreuz an ein CTrade-verwandtes Objekt mittels eines Ereignisses mitzuteilen, ohne von der Existenz von CTrade wissen zu müssen, ist das richtig?
 
Amir Yacoby:
Was mir im Verständnis des Ereignismodells in Verbindung mit OO und MQL5 zu fehlen scheint, ist die Frage, was die richtige Art des Dispatchings der Ereignisse ist.
Ich meine, wie und wo man entscheidet, wer (welche Klasse) was (Ereignis) bekommt.
Es ist klar, dass der oberste Dispatcher, der sprachliche, d.h. der sprachliche ::OnChartEvent nur einmal in einem Projekt geschrieben wird, in der obersten Klasse.

Was ist dann von hier aus der richtige Weg oder die richtigen Wege, um Ereignisse an verschiedene Objekte zu verteilen?
Sollte es eine Ereignisverteilungsklasse geben? Sollte es nur im ::OnChartEvent auf der Grundlage von if-Anweisungen geschehen?
Das ist überhaupt keine Frage. OOP basiert auf den Grundsätzen der Natur. Die Erde ernährt dich nicht, sie stellt nur die Ressourcen zur Verfügung und es liegt an dir, ob, wann und wo du was brauchst.
 
Amir Yacoby:
OK, ich glaube, ich habe es verstanden. Es gibt ein echtes Problem der Konzeptverschiebung, wenn man von prozedural zu oop kommt.
Wenn ich Sie richtig verstanden habe, dann ist das, was Sie meinen, eine Möglichkeit für die CTrendLine, ihr Preis-Cross einem CTrade-vererbten Objekt mittels eines Ereignisses mitzuteilen, ohne von der Existenz von CTrade wissen zu müssen, ist das richtig?
Ich behaupte ja.
 
So hat eigentlich jedes CObject jetzt einen Platz für ein Objekt, das der Empfänger von Ereignissen ist, und hat auch eine Registrierungsmethode für das zuhörende Objekt, um sich als solches anzumelden, und eine Ereignissendemethode und eine Ereignishandlermethode, die vom Empfänger verwendet wird.

Das ist schön, es erinnert mich an das Beobachter-Muster, nur mit Beobachter hat mehr als eine mögliche Empfänger, die m_reciever ist ein Array von Objekten.

Eigentlich wollte ich einmal den Beobachter zu implementieren und wegen des Mangels an Schnittstellen in MQL oder mehrere Vererbung habe ich nicht. Habe nicht an deine gute Idee gedacht, dass das gleiche Objekt die Schnittstelle auf beiden Seiten erzwingen kann.


 
Amir Yacoby:
So hat jetzt jedes CObject einen Platz für ein Objekt, das der Empfänger von Ereignissen ist, und hat auch eine Registrierungsmethode für das zuhörende Objekt, um sich als solches zu abonnieren, und eine Ereignissendermethode und eine Ereignishandlermethode, die vom Empfänger verwendet wird.

Das ist schön, es erinnert mich an das Beobachter-Muster, nur mit Beobachter hat mehr als eine mögliche Empfänger, die m_reciever ist ein Array von Objekten.

Eigentlich wollte ich einmal den Beobachter zu implementieren und wegen des Mangels an Schnittstellen in MQL oder mehrere Vererbung habe ich nicht. Habe nicht an deine gute Idee gedacht, dass das gleiche Objekt die Schnittstelle auf beiden Seiten erzwingen kann.


Nur um Sie zu ermutigen, ich habe mit MQL4 viel mit Listenern gearbeitet.
 
Ovo Cz:
Nur um Sie zu ermutigen, ich habe mit MQL4 viel mit Listenern gearbeitet.

Danke, aber ich fühle mich nicht ermutigt (:

Ich habe es geschafft, aber nicht mit einem Vertrag zwischen Publisher und Listener, ich meine, der Publisher musste davon ausgehen, dass der Listener die Handling-Methode hat, aber nichts erzwang, dass er sie hat.
Oder ich müsste alle Hörer von einem Haupt-Hörer-Objekt erben - aber dann würde ich natürlich jeden Sinn verlieren, weil sie nicht von anderen Klassen erben können.

Wie auch immer, ich bin ein Profi im Programmieren, aber definitiv nicht in OO, wo ich noch keine Erfahrung habe, und ich konkurriere nicht mit einem von euch erfahrenen OO-Programmierern wie Doerk.
Was ich herausgefunden habe, ist, dass man als prozeduraler Programmierer gute Logik- und Programmierfähigkeiten hat, aber die Umstellung ist geistig schwer, besonders wenn ein prozedural orientierter Programmierer wie ich mit der Aufgabe konfrontiert wird, ein OO-Framework zu bauen, ist das ein völlig anderer Geisteszustand. Und das GUI-Teil-Framework ist das detaillierteste Framework mit vielen Ereignissen, um die man sich kümmern muss, ich denke, ihr werdet mir zustimmen, dass es unter den Frameworks das am schwierigsten zu erstellende ist.

12345
Neuer Kommentar