Gemeinkosten für die PLO - Seite 4
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Meine Erfahrung zeigt, dass Sie das müssen.
Ich habe diesen Weg vor etwa fünf Jahren eingeschlagen, damals noch mit MT4. (Nicht, weil ich keine Ahnung von OOP hatte, sondern weil ich zu faul war, mich mit Schnittstellen und Vererbung zu beschäftigen, zumal sich MT4 und MT5 damals in Bezug auf die MQL-Implementierung deutlich unterschieden). Dies führte mich zu der Erkenntnis, dass dies ein Trugschluss ist. Dies ist keine "Weisheit", sondern eine ziemlich vernünftige Einschränkung, eine Art "narrensicher". Wenn Sie sich immer daran erinnern, wofür jede von Hunderten von Variablen zuständig ist, brauchen Sie keine Kapselung. Daran kann ich mich nicht erinnern, und ich ziehe es vor, in jedem Programmblock so wenige Einheiten wie möglich zur Verfügung zu haben.
Sobald MQL4 OOP erschien, begann ich, alle meine Entwicklungen in eine einzige Form zu übersetzen, die auf Schnittstellen basiert.
Ich habe immer noch nichts Bequemeres gefunden als das MQL4-Bestellsystem. Wenn Sie ein Beispiel haben, zeigen Sie es mir bitte.
Alle Handels-APIs, die ich gesehen habe, sehen im Vergleich zu MQL4 monströs aus. Sie sind auch ungeschickt.
Ich habe mir noch nie etwas Bequemeres als ein MQL4-Bestellsystem vorstellen können. Wenn Sie ein Beispiel haben, zeigen Sie es mir bitte.
Alle Handels-APIs, die ich gesehen habe, sehen im Vergleich zu MQL4 monströs aus. Und außerdem sind sie ungeschickt.
Was soll dabei herauskommen, jeder Parameter muss in einer eigenen Funktion gezeichnet werden. Es wäre logischer, die Struktur mit allen Parametern auf Anfrage zu erhalten, wie bei Ticks.
Ich habe mir noch nie etwas Bequemeres als ein MQL4-Bestellsystem vorstellen können. Wenn Sie ein Beispiel haben, zeigen Sie es mir bitte.
Alle Handels-APIs, die ich gesehen habe, sehen im Vergleich zu MQL4 monströs aus. Und außerdem sind sie ungeschickt.
Wie meinen Sie das?
Die Essenz der Aufträge ? Ja, ich stimme zu, das ist sehr praktisch.
Aber gerade die Anwendung von OOP auf dieses System ist meiner Meinung nach das, was den größten "Gewinn" bringt. Sagen wir, ich habe die gleiche Schnittstelle - gibt sowohl MT4 Position bestehend aus Aufträgen und MT5 Position bestehend aus MT5 Positionen, und unabhängig davon, ob Hedging oder Netting Bedingungen.
Meiner Meinung nach ist es viel logischer und verständlicher, wenn wir eine Liste von Auftragsobjekten (oder MT5-Positionen) haben, die wir über die Funktion Select() erhalten, und wir die Eigenschaften der Aufträge ansprechen, anstatt den"Umgebungszustand" (den wir über dieselbe Funktion erhalten), den wir über Funktionen ansprechen.
Das Interessanteste ist, wenn wir mehrere Aufträge auf einmal verfolgen müssen - in diesem Fall führt der prozedurale Ansatz unweigerlich zu einem "Pseudo-Objekt"-Ansatz - wir müssen ein Array mit Informationen über Aufträge erstellen, die bei der Eingabe von OnTick() aktualisiert werden sollen, und mit den Auftragsdaten durch Indizes im Array arbeiten, genau wie bei OOP-Zeigern auf Auftragsobjekte.
Darüber hinaus würde uns der OOP-Ansatz einen Vorteil verschaffen, wenn wir gleichzeitig mit historischen und aktiven Aufträgen arbeiten, da die Schnittstelle für historische Aufträge der Nachfolger des aktiven Auftrags ist. Der verfahrenstechnische Ansatz bedeutet außerdem, dass historische und aktive Aufträge von unterschiedlichen Funktionen bearbeitet werden, was sehr viel unpraktischer ist.
Das Gute daran ist, dass jeder Parameter von einer separaten Funktion gezogen werden muss. Es wäre logisch, die Struktur mit allen Parametern auf Anfrage zu erhalten, genau wie bei Ticks.
Die Einträge Order.TakeProfit und OrderTakeProfit() sind identisch. Der erste hat nur die Möglichkeit, das Objekt zu speichern, und der zweite - Relevanz. Das Bedürfnis nach Aufbewahrung wird nur sehr selten befriedigt, und zwar nicht in TS. Und da ist es kein Problem, die Struktur zu schaffen.
Ich selbst habe mich gefragt, warum die Entwickler die Rückgabe der Bestellstruktur nicht gemacht haben und jedes Feld separat über eine Funktion belassen haben (für die Historie ist auch jedes Mal ein Ticket erforderlich).
Im Allgemeinen sehe ich nicht wirklich etwas falsch mit MQL4-API (es kann nicht nur in MT4/5 funktionieren).
Wie meinen Sie das?
Das eigentliche Wesen des Auftragshandels ? Ja, ich stimme zu, sehr praktisch.
Aber gerade die Anwendung von OOP auf dieses System ist - meiner Meinung nach - der größte "Gewinn". Nehmen wir an, ich habe die gleiche Schnittstelle - gibt sowohl MT4 Position, bestehend aus Aufträgen und MT5 Position, bestehend aus MT5 Positionen, und unabhängig davon, ob es abgesichert ist oder Netting.
Sie haben Ihr eigenes Tuch, der andere hat sein eigenes Tuch. Die Frage war, ob es möglich ist, einen bequemeren Wrapper als MQL4 zu erstellen.
Es ist meiner Meinung nach viel logischer und verständlicher, wenn wir eine Liste von Auftragsobjekten (oder MT5-Positionen) haben, die wir mit der Funktion Select() erhalten, und wir greifen auf die Auftragseigenschaften zu, anstatt auf den"Umgebungsstatus" (den wir mit derselben Funktion erhalten), auf den wir über Funktionen zugreifen.
Das Interessanteste ist, wenn wir mehrere Aufträge auf einmal verfolgen müssen - in diesem Fall führt der prozedurale Ansatz unweigerlich zu einem "Pseudo-Objekt"-Ansatz - wir müssen ein Array mit Informationen über Aufträge erstellen, die bei der Eingabe von OnTick() aktualisiert werden sollen, und Auftragsdaten durch Indizes im Array auf dieselbe Weise behandeln, wie wir OOP-Zeiger auf Auftragsobjekte behandeln.
Ich habe darüber in einem früheren Beitrag geschrieben.
Außerdem würde uns der OOP-Ansatz einen Vorteil verschaffen, wenn wir gleichzeitig mit historischen und aktiven Aufträgen arbeiten - denn die Schnittstelle des historischen Auftrags ist ein Erbe des aktiven Auftrags. Die meisten Funktionen sind gleich. Und der verfahrenstechnische Ansatz erlaubt es uns, historische und aktive Aufträge mit unterschiedlichen Funktionen zu bearbeiten, was sehr viel unpraktischer ist.
Nun, in MQL4 wird die Historie mit denselben Funktionen behandelt (OrdersHistoryTotal zählt nicht).
Es wäre gut, ein Codebeispiel zu haben, bei dem die eigene Handels-API eindeutig besser ist als die MQL4-API. Ich selbst verwende OOP fast überall. Und für einige spezifische Aufgaben mache ich einige Handelsverpackungen. Aber sie sind nicht universell einsetzbar, auch wenn sie für bestimmte Aufgaben sehr praktisch sind. Ich möchte jedoch noch die universellen Handels-APIs vergleichen.
Ich selbst habe mich gefragt, warum die Entwickler die Rückgabe der Bestellung nicht zu einer Struktur gemacht haben, sondern jedes Feld einzeln über eine Funktion belassen haben (für die Historie ist auch jedes Mal ein Ticket erforderlich).
Alexey Volchanskiy:
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
In MT5 gab es zwar Strukturen, aber die Rückgabe erfolgte weiterhin über Funktionen.
Forum zum Thema Handel, automatische Handelssysteme und Strategietests
Gemeinkosten für OOP
fxsaber, 2017.07.07 08:08
Die Frage war anders, ist es möglich, einen Wrapper bequemer als MQL4 erstellen?
In MT5 gab es zwar Strukturen, aber die Rückgabe erfolgte trotzdem über Funktionen.
Vielleicht haben sie beschlossen, die Tradition nicht zu brechen, aber sie hätten es tun sollen.
Ich verstehe, wenn die Daten vom Server des Maklerunternehmens heruntergeladen wurden, aber es ist lokal, es wird sofort genommen, wir könnten die Struktur sofort füllen
Sie haben wahrscheinlich beschlossen, nicht mit der Tradition zu brechen, obwohl sie es hätten tun sollen.
Ich verstehe, wenn die Daten vom DC-Server heruntergeladen wurden, aber sie sind lokal, sie werden sofort genommen, man könnte die Struktur sofort füllen
Ja, während SELECT füllen wir nur eine Instanz einer versteckten Struktur, auf deren Felder nur über const(read-only)-Funktionen zugegriffen werden kann.
Wahrscheinlich ist dies die einzige fragwürdige Entscheidung des Handels-API-Kerns. Ansonsten weiß ich gar nicht, worüber ich mich beschweren soll.
Ja, wenn SELECT verwendet wird, füllt es eine Instanz einer verborgenen Struktur, auf deren Felder nur über const(read-only)-Funktionen zugegriffen werden kann.