Diskussion zum Artikel "Entwicklung eines Expertenberaters für mehrere Währungen (Teil 4): Schwebende, virtuelle Aufträge und Speicherstatus"
Ich würde eine solche Architektur nicht verwenden.
Stellen Sie sich vor, MQ würde virtuellen Handel in die Sprache einbauen. Dann käme man nicht auf die Idee, andere Entitäten darin einzubetten, weil das einfach nicht durch OOP-Vererbung möglich ist - die Quellen sind nicht verfügbar. Sie würden eine andere Architektur schaffen.
Grafische Objekte in einer Virtualisierung - nun, das ist alles wieder auf dem gleichen Haufen.
Die Architektur ist so unhandlich geworden, dass man sich dabei unwohl fühlt. Anstatt sie aus einfachen Bausteinen zusammenzusetzen, haben Sie beschlossen, universelle Bausteine zu erstellen.
Wir sind wieder dabei, die Umsetzung nicht wirklich zu mögen, aber andere (die noch nicht fertig sind, aber angedacht wurden) noch weniger zu mögen. Vielleicht wird es im Laufe der weiteren Entwicklung möglich sein, es anders zu machen, aber für jetzt.
Zur Situation mit den unzugänglichen Quellen: In dieser Implementierung habe ich beschlossen, die Tatsache auszunutzen, dass die Quellen verfügbar sind und man etwas zu ihnen hinzufügen kann, was nicht sofort notwendig war, um sie hinzuzufügen. Ich habe versucht, solche Ergänzungen minimal zu halten. Die Alternative wäre gewesen, mehrere neue Erbenklassen für die CVirtual*-Klassenfamilie zu erstellen. Dieser Ansatz erschien mir noch umständlicher. Aber es ist gut möglich, dass wir dazu kommen werden, wenn es mehr Klassen gibt und es unschön wird, sie in einem Ordner zu speichern.
Ich brauchte grafische Objekte, um die Entwicklung von Handelsstrategien zu steuern, also wurden sie implementiert. Und die Klasse CVirtualOrder wurde überhaupt nicht verändert. Allerdings musste ich der Klasse CVirtualReceiver vier neue Codezeilen hinzufügen. Ich habe mich für diese Option unter verschiedenen möglichen Optionen entschieden.
Wenn kein Bedarf an der grafischen Darstellung virtueller Positionen besteht, kann man sie entweder nicht verwenden oder zur Bibliotheksvariante aus dem vorherigen Artikel zurückkehren.
Wir sind wieder dabei, die Implementierung nicht wirklich zu mögen, aber andere (die noch nicht fertig sind, aber angedacht wurden) noch weniger zu mögen. Vielleicht wird es in der weiteren Entwicklung möglich sein, Dinge anders zu machen, aber im Moment ist es so, wie es ist.
Leider habe ich nicht genug Zeit, um meine Vision am Beispiel des partiellen Refactorings zu zeigen.
Nach dem ersten Start eröffnet der Expert Advisor virtuelle und reale Positionen, berechnet vielleicht einige Indikatoren auf Basis von Preisdaten. Diese Informationen sind es, die den Zustand des EA als Ganzes ausmachen. Wenn Sie nun das Terminal neu laden, sollte der EA nicht nur die offenen Positionen als seine eigenen erkennen, sondern auch alle seine virtuellen Positionen und die notwendigen Berechnungswerte wiederherstellen. Wenn die Informationen über offene Positionen vom Terminal abgerufen werden können, müssen die Informationen über virtuelle Positionen und Berechnungswerte vom Expert Advisor selbst gespeichert werden.
Stellen Sie sich vor, dass der Expert Advisor auf zwei Handelskonten eines Brokers arbeitet. Eines der Terminals ist ausgeschaltet. Während dieser Zeit haben sich die virtuellen Positionen auf dem laufenden Konto geändert. Wie kann man das Verhalten des Expert Advisors mit dem Terminal, das nicht abgeschaltet wurde, in Einklang bringen?
Wie ich es mache. Ich speichere die virtuellen Positionen überhaupt nicht. Beim Start des Expert Advisors werden alle internen TSs im virtuellen Tester vor dem aktuellen TimeCurrent gestartet. So erhalten wir, dass im nachgeladenen EA alle Daten zum aktuellen Zeitpunkt mit der Version ohne Nachladen übereinstimmen.
Mit "Nachladen" meinen wir auch die Situation, wenn eine Pause in der Arbeit des Expert Advisors entsteht. Zum Beispiel, eine lange OrderSend oder reping. Aus diesem Grund ist es notwendig, Kursdaten ab dem Zeitpunkt der letzten Anfrage anzufordern. Und sie in einer virtuellen Maschine auszuführen.
Leider ist die Zeit zu knapp, um meine Vision anhand eines Beispiels für partielles Refactoring zu zeigen.
Sie schenken der Überprüfung des Codes anderer Leute bereits viel Aufmerksamkeit, wofür ich Ihnen sehr dankbar bin.
Stellen Sie sich vor, dass ein Expert Advisor auf zwei Handelskonten desselben Brokers arbeitet. Ein Terminal ist ausgefallen. In dieser Zeit haben sich die virtuellen Positionen auf dem laufenden Konto geändert. Wie kann man das Verhalten des Expert Advisors an das des Terminals anpassen, das nicht ausgefallen ist?
Ich bin auf eine solche Situation gestoßen, aber es war ein unbedeutender Faktor, der das Handelsergebnis beeinflusste. Außerdem gab es Zeiten, in denen das Terminal, das die Schließung von Positionen "verschlief", diese zu einem günstigeren Preis schloss. Die Gewährleistung der vollständigen Identität war also kein Selbstzweck.
Und wenn es verschiedene Broker gibt, können selbst synchron arbeitende Expert Advisors aufgrund kleiner Unterschiede bei den Kursen leicht unterschiedliche Ergebnisse anzeigen. Trotzdem sollte man die Identität anstreben.
Wie ich es mache. Ich speichere überhaupt keine virtuellen Konten. Beim Starten eines Expert Advisors werden alle internen TS im virtuellen Tester vor dem aktuellen TimeCurrent gestartet. So erreichen wir, dass im nachgeladenen Expert Advisor alle Daten zum aktuellen Zeitpunkt mit der Version ohne Nachladen übereinstimmen.
Das ist ein interessanter Ansatz, ich habe diese Möglichkeit bisher nicht in Betracht gezogen. Wenn ich es richtig verstehe, müssen wir, wenn wir sie verwenden, ein festes Datum für den Beginn des virtuellen Handels haben, und es muss für verschiedene Instanzen von Expert Advisors in verschiedenen Terminals dasselbe sein. Das ist nicht schwierig. Und es muss ein virtueller Tester implementiert werden oder Ihr vorgefertigter verwendet werden. Dies ist etwas komplizierter.
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Neuer Artikel Entwicklung eines Expertenberaters für mehrere Währungen (Teil 4): Schwebende, virtuelle Aufträge und Speicherstatus :
Nachdem wir mit der Entwicklung eines Mehrwährungs-EAs begonnen haben, konnten wir bereits einige Ergebnisse erzielen und mehrere Iterationen zur Verbesserung des Codes durchführen. Unser EA war jedoch nicht in der Lage, mit schwebenden Aufträgen zu arbeiten und den Betrieb nach dem Neustart des Terminals wieder aufzunehmen. Fügen wir diese Funktionen hinzu.
Im vorigen Artikel haben wir die Code-Architektur erheblich überarbeitet, um einen Multiwährungs-EA mit mehreren parallel arbeitenden Strategien zu erstellen. In dem Bemühen um Einfachheit und Klarheit haben wir bisher nur ein gewisses Mindestmaß an Funktionalität berücksichtigt. Selbst wenn man die Grenzen unserer Aufgabe berücksichtigt, haben wir den Code gegenüber den früheren Artikeln erheblich verändert.
Jetzt haben wir hoffentlich die Grundlagen geschaffen, die ausreichen, um die Funktionalität ohne radikale Änderungen am bereits geschriebenen Code zu erhöhen. Wir werden uns bemühen, nur dort ein Minimum an Bearbeitungen vorzunehmen, wo es wirklich notwendig ist.
Als weitere Entwicklung werden wir versuchen, Folgendes zu tun:
Beginnen wir mit der einfachsten Sache - der Bearbeitung virtueller, schwebender Aufträge.
Autor: Yuriy Bykov