Strukturregeln. Lernen, wie man Programme strukturiert, Erforschung von Möglichkeiten, Fehlern, Lösungen usw. - Seite 18
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
Oh, Vladimir, das ist gar nicht so einfach mit deiner Schaltung. Sie sagen also, dass Sie nur den Treiber neu schreiben müssen? Aber ich habe viel mehr plattformabhängige Teile gezählt:
Wie erhalten Sie die Markt- und Handelshistorie? Und die Informationen über die aktuelle Position werden nicht zufällig vom Terminal übernommen? Und wenn Sie das Volatilitätsmodul implementieren müssen - eine weitere plattformabhängige API?
Werden Sie Adapter schreiben? Wie viele von ihnen wird es geben? Für die Markthistorie - ein Adapter, für die Handelshistorie - ein weiterer, für die Arbeit mit den Positionen - ein dritter. Am Ende gibt es also doppelt so viele Module und die gleiche Menge an plattformabhängigem Code.
So sehe ich das Problem nicht.
Nur alles, was rot ist, ist ziemlich stabil, alles, was von der Plattform kommt nicht im Laufe der Jahre ändern, wenn Sie für eine andere Plattform benötigen, gibt es auch eine gut etablierte API, umschreiben kein Problem.
Aber alle Module mit grünen Pfeilen sind ihre eigenen, und fast immer aktive Nacharbeit (es gibt keine Grenze für das Ideal).
Die Richtungsprognose wurde geschrieben, dann kam die neue Idee zu vertiefen und zu erweitern, gut, wie jetzt ist es zu kaufen, aber wir müssen bereit für den Verkauf zu bekommen, langsam reduzieren das Volumen.
Also habe ich begonnen, zwei Module zu verwenden.
MM Corrector ist ebenfalls ein dynamisches System, das jetzt mit Positionen arbeitet, dann aber plötzlich eine Idee hat und beschließt, es für Long-Positionen zu ändern (sanfter Markteintritt).
Market Driver sollte stabil sein, da er einen Ausgang zu einer plattformabhängigen API hat, daher ist die Formalisierung klar, aber es wird viele Wendungen geben, da die API eine Vielzahl von Möglichkeiten bietet.
So sehe ich das Problem nicht.
Einfach alles, was rot ist, ist ziemlich stabil, alles, was von der Plattform kommt, ändert sich seit Jahren nicht, wenn man es für eine andere Plattform braucht, gibt es auch eine gut etablierte API, das Umschreiben ist kein Problem.
Eine der wichtigsten Ideen in diesem Schema ist nicht die Anzahl der plattformabhängigen Teile, sondern deren strikte Lokalisierung. Das heißt: TS selbst (Prädiktoren + MM-Module) - es ist ein plattformunabhängiges Design, aber die Datenquellen sind Indikatoren und Markttreiber, bzw. abhängig (Handelsgeschichte, gefüttert, um den Eingang der Empfehlungen Korrektor - ist auch im Wesentlichen der Indikator).
Die Folge - eine klar begrenzte, deutlich abgrenzbare und sich nicht überschneidende Interventionszone bei
1. Migration.
2. Verbesserung der TS, insbesondere der Skalierung.
Aber alle Module mit grünen Pfeilen sind ihre eigenen, und fast immer eine aktive Neugestaltung (es gibt keine Grenze für das Ideal).
Die Richtungsprognose wurde geschrieben, dann kam die neue Idee zu vertiefen und zu erweitern, gut, wie jetzt ist es kaufen, aber wir müssen für den Verkauf vorzubereiten, langsam das Volumen zu reduzieren.
Also habe ich begonnen, zwei Module zu verwenden.
Der MM Corrector ist ebenfalls ein dynamisches System, das zunächst mit der Position arbeitet, dann aber plötzlich klug wird und beschließt, die Position in Aktien umzuwandeln (sanfter Markteintritt).
Der Markttreiber sollte stabil sein, weil er eine Ausgabe an die plattformabhängige API hat, daher ist die Formalisierung klar, aber es wird ein großes Durcheinander geben, weil die API eine Menge Funktionen bietet.
Niemand hat die Abwesenheit von Komplikationen versprochen :) Aber denken Sie daran, dass all diese direkten API-Aufrufe nicht im Treiber lokalisiert sind, sondern mit Codes von Prädiktoren und MM-Modulen vermischt sind: .............
;)
Nikolay, Ihr Beitrag ist sehr vernünftig, aber ich verpflichte mich, die vorgeschlagene Regelung (ihre Universalität) zu verteidigen.
Ich stimme zu, ich möchte nur klarstellen (und die Gelegenheit nutzen) für Vasily. Eine der wichtigen Ideen in dem Schema ist nicht die Anzahl der plattformabhängigen Teile, sondern ihre strikte Lokalisierung. Das heißt: TS selbst (Prädiktoren + MM-Module) - es ist ein plattformunabhängiges Design, aber die Datenquellen sind Indikatoren und Markttreiber, bzw. abhängig (Handelsgeschichte, gefüttert, um den Eingang der Empfehlungen Korrektor - ist auch im Wesentlichen der Indikator).
Die Folge - eine klar begrenzte, deutlich abgrenzbare und sich nicht überschneidende Interventionszone bei
1. Migrationen.
2. Verbesserung der TS, insbesondere der Skalierung.
Wenn wir uns jedoch sorgfältig an die Trennung von plattformabhängigen/unabhängigen Teilen des Systems halten, dann können wir zum Beispiel in unserer aktuellen Situation die Entwicklung von EAs für beide Plattformen (MT4/5) problemlos unterstützen, was bei plattformabhängigen Handelssystemen ein Problem wäre.Innerhalb der im Schema markierten Komponenten kann es beliebig viele Module geben. Das ist normal. Ich denke, dass nur deren klare Pipeline-Anordnung sinnvoll ist. Diese sollten im Code nicht ohne absolut unvermeidbare Notwendigkeit vermischt werden, d.h. Sie sollten das Mischen so weit wie möglich vermeiden, damit Sie bei der Skalierung in Richtung Multitools immer gut definierte und bequeme Andockpunkte für die Module haben. Betrachten Sie das Schema aus diesem Blickwinkel, Sie werden es selbst finden.
Siehe oben // Aber der MM-Korrektoreingang ist der bequemste Punkt, um eine Wolke von Einzelwährungsprädiktoren (genauer gesagt Einzelinstrumenten) in die Multiwährungs- (Multiinstrumenten-) Küche zu integrieren.Niemand hat versprochen, dass es keine Komplexität gibt :) Aber denken Sie daran, dass all diese direkten API-Aufrufe nicht im Treiber lokalisiert sind, sondern mit Codes von Prädiktoren und MM-Modulen vermischt sind: .............
;)
OK, lassen Sie uns das als Grundlage nehmen (aber fügen Sie ein Stoppmodul hinzu, das scheint vernünftig zu sein und niemand hat Einwände),
und überlegen, was in diesem Schema noch fehlt, oder es überarbeiten.
OK, nehmen wir es als Grundlage (aber fügen Sie ein Modul für die Arbeit mit Haltestellen hinzu, da dies sinnvoll erscheint und niemand Einwände hat),
und überlege, was in dieser Schaltung noch fehlt, oder überarbeite sie.
Ich werde über eine Nachbesserung nachdenken (lassen Sie es kochen).
Der Mangel ist noch offensichtlicher - diesem Schema fehlt offensichtlich das GUI (visuelles Überwachungs-/Steuerungs-Subsystem). Ich möchte ein einheitliches (und bequemes!) Schema für die Interaktion des Expert Advisors mit dem GUI entwickeln. Bisher bin ich in dieser Sache spontan, was mich wirklich ärgert. Ich möchte das gleiche Ziel erreichen (vollständige Datenabstraktion in beide Richtungen). Deshalb habe ich die EA/GUI-Schnittstellenaufgabe für die Ausbildung vorgeschlagen, ich bin daran kaufmännisch interessiert, ich wollte ein paar Ideen aus der Öffentlichkeit bekommen.
Innerhalb der hervorgehobenen Schemakomponenten kann es beliebig viele Module geben. Das ist normal. Ich finde es nur sinnvoll, deren klare Pipeline-Anordnung zu haben. Die sollte innerhalb des Codes nicht ohne absolut unumgängliche Notwendigkeit umgeschichtet werden, d.h. So haben Sie bei der Skalierung in Richtung Multitools immer gut definierte und bequeme Andockpunkte. Sehen Sie sich das Diagramm aus diesem Blickwinkel an und Sie werden es selbst finden.
Eine unbegrenzte Zersiedelung der Landschaft führt zu ernsthaften Problemen in der Zukunft. Sie haben die Logik des Expert Advisors praktisch in verschiedene Module aufgeteilt. Die Module selbst werden miteinander interagieren, und es gibt keine Garantie, dass die Verbindungen zwischen ihnen nicht zu einem Gewirr werden. Imho sind alle grün markierten Quadrate Elemente eines Handelssystems. Ihre Aufteilung in verschiedene Module verstößt gegen eines der wichtigsten Programmierprinzipien: die Kapselung von Daten und Methoden innerhalb einer Aufgabe.
Da alle begonnen haben, ihre eigenen Pläne zu veröffentlichen, werde auch ich damit fortfahren. Diesmal ist es ein noch abstrakteres Schema:
Schwarze Pfeile beschreiben starre Beziehungen. Die grauen Felder sind private Zusammenhänge innerhalb des Moduls, sie sind nicht wichtig. Außerdem kann die Handelsroboterklasse die Plattform-API direkt ansprechen, aber die Plattformunabhängigkeit ist geringer.
Eine unbegrenzte Zersiedelung der Landschaft führt zu ernsthaften Problemen in der Zukunft. Sie haben die Logik des Expert Advisors praktisch in verschiedene Module aufgeteilt. Die Module selbst werden miteinander interagieren, und es gibt keine Garantie dafür, dass die Verbindungen zwischen ihnen nicht zu einem Gewirr werden. Imho sind alle grün markierten Quadrate Elemente eines Handelssystems. Ihre Aufteilung in verschiedene Module verstößt gegen eines der wichtigsten Programmierprinzipien: die Kapselung von Daten und Methoden innerhalb einer Aufgabe.
Da alle begonnen haben, ihre eigenen Pläne zu veröffentlichen, werde auch ich damit fortfahren. Dieses Mal ist es ein noch abstrakteres Schema:
Schwarze Pfeile beschreiben starre Beziehungen. Die grauen Felder sind private Zusammenhänge innerhalb des Moduls, sie sind nicht wichtig. Außerdem hat die Handelsroboterklasse das Recht, direkt auf die API der Plattform zuzugreifen, was jedoch die Plattformunabhängigkeit verringert.
Was die Neugestaltung und Verbesserung betrifft, so werde ich darüber nachdenken (und es ausklingen lassen).
Der Mangel ist offensichtlicher - diesem Schema fehlt offensichtlich die GUI (visuelles Überwachungs-/Steuerungs-Subsystem). Ich möchte ein einheitliches (und bequemes!) Schema der Interaktion zwischen dem Expert Advisor und der GUI entwickeln. Bisher bin ich in dieser Sache spontan, was mich wirklich ärgert. Ich möchte das gleiche Ziel erreichen (vollständige Datenabstraktion in beide Richtungen). Deshalb habe ich die EA/GUI-Schnittstellenaufgabe für die Ausbildung vorgeschlagen, ich bin daran kaufmännisch interessiert, ich wollte ein paar Ideen aus der Öffentlichkeit bekommen.
Gehen Sie von der Aufgabe aus. Was sind die am meisten geforderten Aufgaben in der GUI?
Gehen Sie von dort aus. Beschreiben Sie, was Sie wollen, wählen Sie allgemeine Überschriften aus, erstellen Sie einen Rahmen, fügen Sie dann weitere Dinge hinzu und sehen Sie, wie einfach es ist, den Rahmen zu ändern.
Dann werden Sie verstehen, wie es sein sollte, schreiben Sie es noch einmal neu. Ich sehe das so.
MetaDriver sagt es richtig, und sein System ist korrekt. Dick_fx würde auch hinzufügen, dass der "Trading Driver" mit 10-20 Plattformen arbeiten sollte, um die besten Preise zu nutzen.
Die Verwendung eines solchen korrekten Systems ist jedoch nur unter idealen Bedingungen sinnvoll - keine Fehler in der Strategie, kein Eingreifen des Benutzers, keine höhere Gewalt... In der Realität ist dies jedoch selten der Fall.
Lassen Sie mich ein Beispiel von dick_fx geben: 25 Strategien arbeiten, der Aggregator (Trade Driver) sammelt sie zu einer Nettoposition und setzt sie in den Markt, alles ist in Ordnung. Plötzlich läuft bei der 17-ten Strategie etwas schief und sie gibt ungesunde Prognosen ab - sie sagt, man solle bei 50 % der Einlage eröffnen. Expert Advisor öffnet sich gehorsam.
Was macht ein triviales Schließfach a la MT4:
Kommen wir nun zur "korrekten Buchführung". Was sollte der Händler tun, um den Fehler zu korrigieren (ein 50%iger Margenhandel - ein offensichtlicher Logikfehler)?
Die Frage ist: Was ist einfacher? Offensichtlich ist die Variante mit MT4.
Und was ist billiger? Offensichtlich die Option Netting.
Was ist die Schlussfolgerung? Erstellen Sie einen Markttreiber mit einem GUI von MT4 ;)
Und noch eine Sache.
Dies ist die ganze Argumentation der "richtigen" Händler und sogar der Programmierer. Wenn sie es zu ihrem eigenen Vergnügen tun, auf dem Konto mit einer guten Einlage, dann ist es die einzige Möglichkeit, es zu tun.
Wenn wir uns mit dem Schreiben von Experten befassen, stellt sich heraus, dass niemand es "richtig" braucht. Die Menge der Händler-Kunden kann nicht geändert werden, also muss man "für sie" schreiben.
Die Option "meinen Job kündigen" wird akzeptiert! =)
Und noch eine Sache.
Dies ist die ganze Argumentation der "richtigen" Händler und sogar der Programmierer. Wenn sie es zu ihrem eigenen Vergnügen tun, auf dem Konto mit einer guten Einlage, dann ist es die einzige Möglichkeit, es zu tun.
Wenn wir uns mit dem Schreiben von Experten befassen, stellt sich heraus, dass niemand es "richtig" braucht. Die Menge der Händler-Kunden kann nicht geändert werden, also muss man "für sie" schreiben.
Die Option "meinen Job kündigen" wird akzeptiert! =)