Mein Ansatz. Der Kern ist der Motor. - Seite 16
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
Im Moment habe ich einen Kunden. Ich erledige seine Aufgaben sehr schnell. 3-4 Stunden und ein neues, voll funktionsfähiges Fenster ist fertig. Zusammen mit der Verbindungsschnittstelle. Ich behebe auch schnell Fehler in der Engine und schicke ihm neue Versionen. 9 Fenster in ein paar Tagen + Änderungen an der Engine, Fehlerbehebungen, neue Funktionen... Alles sehr schnell.
Sie müssen eine Menge Freizeit haben.
Sie verstehen, dass Sie allein nicht genug sind. Der Umfang Ihrer Engine wird davon abhängen, ob andere Programmierer sie mögen (Sie allein sind nicht genug für alle Kunden). Und wenn es den Progerms nicht gefällt, dann... ach, das Schicksal deiner Schöpfung wird glorreich sein.
Die Programmierer müssen sich nicht mit dem Motorcode befassen. Sie erhalten die Verbindungsschnittstelle dazu in der Datei. Ich habe es bereits getestet. Alles funktioniert.
Im Moment habe ich einen Kunden. Ich erledige seine Aufgaben sehr schnell. 3-4 Stunden und ein neues, voll funktionsfähiges Fenster ist fertig. Zusammen mit der Verbindungsschnittstelle. Ich behebe auch schnell Fehler in der Engine und schicke ihm neue Versionen. 9 Fenster in ein paar Tagen + Änderungen an der Engine, Fehlerbehebungen, neue Funktionen... Alles sehr schnell.
Steht es da richtig? 3-4 Stunden für die Erstellung eines Fensters? Keine Minuten?
Ich mache das jetzt schon seit über einem Jahr. Und ich bin nicht verwirrt.))
Zum Vergleich: Implementieren Sie dieselbe Sache mit OOP. Vielleicht gefällt es Ihnen ja. :)
Steht es da richtig? 3-4 Stunden für die Erstellung eines Fensters? Keine Minuten?
Nein. Sie können dies in wenigen Minuten tun, wenn Sie den Code aus einem anderen Fenster kopieren und Änderungen vornehmen. Aber ich sprach davon, es von Grund auf neu zu erstellen, über Grafiken nachzudenken und am Stil zu arbeiten.
Übrigens, Peter, vergessen Sie nicht, alle Arten von Diagrammen hinzuzufügen, wie Indikatoren, nur in Windows, mit Unterstützung für eine Reihe von Datenformaten (OHLC, wie Zigzag, etc.). Ich hoffe, dass dies alles in Ihrem Projekt leicht umsetzbar ist.
Ich werde es versuchen.
Ich werde es versuchen.
Ich werde es nicht versuchen, ich werde es tun). Erhöht die Nützlichkeit Ihrer Kreation.
Steht es da richtig? 3-4 Stunden für die Erstellung eines Fensters? nicht Minuten?
Was für ein Unsinn... die Erstellung von 3 Fenstern in MQL sogar mit Bibliotheken aus dem Standard-MT-Toolkit dauert 10 Minuten und weitere 20-30 Minuten, um Höhe und XY der Schaltflächen, Bearbeitungen, Beschriftungen... anzupassen.
Ich sehe 2 Möglichkeiten, warum die Arbeit von Petr nützlich sein könnte:
- Erstellung einer separaten Anwendung zur Generierung von MQL-Quellcode, d.h. GUI-Konstruktor und ohne auf die Einzelheiten der Funktionsweise einzugehen, sozusagen Visual MQL++ )))
- Oder: Es gibt Menschen, die sich ihre Schwierigkeiten selbst schaffen und sie dann erfolgreich überwinden © Wingston Churchill
Mir scheint, dass sich alle OOP-Komponenten von Peter ständig an Details festklammern.
Und der Kern des Problems liegt genau in der Philosophie und Architektur des Systems.
Es wurde oben zu Recht gesagt, was die strittigen Punkte sind, die für Peter Vorteile und für seine Gegner Nachteile zu sein scheinen:
- Heap von global zugänglichen Variablen, keinerlei Kapselung.
- fehlende Typenkontrolle
- eine starre Abhängigkeit von einer bestimmten Implementierung der Datenspeicherung.
Und Peter hat ganz richtig gesagt, dass das Konzept der OOP (zumindest in meinen Vorschlägen) auf Vereinfachung abzielt, "basierend auf der Bequemlichkeit des Programmierers". Kapselung, Typkontrolle, Schnittstellen - all das ist darauf ausgelegt, die Möglichkeit von Fehlern, Verwirrung und Missbrauch so weit wie möglich auszuschließen. Das ist richtig.
Das Konzept von Peter ist das Gegenteil. Alle Daten sind von überall aus zugänglich, der Benutzer hat von jeder Stelle des Codes aus die volle Kontrolle über alle Objekte im Programm und kann sie nach Belieben wahrnehmen, ohne jegliche Typbeschränkungen (abgesehen von den Einschränkungen von MQL).
Peter sagt, dass dieses Konzept "die maximale Entwicklung ermöglicht. Die Benutzerfreundlichkeit kommt erst an zweiter Stelle".
Ich persönlich als Programmierer mag es schon nicht, wenn die Bequemlichkeit an zweiter Stelle steht. Aber das kann man opfern, wenn man tatsächlich viel mehr Entwicklung bekommt. Nun, ich möchte sehen, was es ist. Wo OOP-Ansatz mit Einschränkungen und Kapselung nicht erlauben, eine solche Entwicklung zu erreichen, wie dieser Ansatz mit vollem Zugriff auf die riesige Reihe von Eigenschaften, in einem Feld von monströsen Größen geworfen. (Ganz zu schweigen von der Notwendigkeit, sich alles zu merken).
Wie oben zu Recht erwähnt, erinnert der Ansatz an Pascals TurboVision. Obwohl Typkontrolle und Kapselungseinschränkungen in dieser Bibliothek bereits implementiert wurden.