Mt4 Ende der Unterstützung. - Seite 28
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
Ich weiß nicht, ob das schon jemand vorgeschlagen hat, aber warum sollte man nicht alles von MT4 auf MT5 umstellen, dann würde jeder weitermachen.
George Merts:
Sie schreiben zuerst die Teile und fügen sie dann zu einem Ganzen zusammen, wobei sie oft feststellen, dass die Teile nicht miteinander kompatibel sind - was übrigens auch den Wunsch erklärt, "Zugang zu allen verfügbaren Variablen zu haben".
Nein, das ist es nicht. Es geht nicht darum, Zugang zu allen möglichen Variablen zu haben, sondern nur zu denen, die man braucht. Dabei handelt es sich in der Regel um Eingangs- und Ausgangsvariablen verschiedener Funktionen.
Das Hinzufügen zusätzlicher Begrenzungen an dieser Stelle wird die Lesbarkeit des Codes sofort erheblich erschweren und die Zahl möglicher Fehler erhöhen, wenn etwas nicht ankommt, weil es aufgrund dieser Begrenzungen auf dem Weg verloren gegangen ist.
Sicherlich verständlicher Wunsch, OOP wenigstens irgendwie für etwas Nützliches zurück zu ziehen, aber solche Fälle liegen meist nicht im Bereich der Programmierung, sondern im kommerziellen Bereich, zum Beispiel für zusätzliche Programmierstunden, Schaffung von endlosen Diskussionen über Architektur von Schnittstellen und ähnlichem angenehmen Zeitvertreib in der Arbeitszeit.
Gibt es im Prinzip ein Beispiel dafür? Auch wenn es nicht Ihre sind? Ich habe große Zweifel. Zu Beginn der zweitausendsten Jahre habe ich aufgehört, die Anzahl der von mir geschriebenen fehlerbereinigten und funktionierenden Programmzeilen zu zählen, weil sie eine Million überschritten hat - es wurde uninteressant. Und ich war nie gezwungen, meine eigene Klasse zu gründen, obwohl die Vielfalt und der Umfang meiner Aufgaben sehr unterschiedlich waren. Ich musste Variablen vom Typ Prozedur verwenden, wenn es notwendig war, die Arbeit für mehrere Personen zu parallelisieren, aber nicht mehr. Warum ist das so?
Der Punkt ist, dass OOP nur auf die Verpackung des fertigen Codes angewandt werden kann und nur in der Phase des Codeschreibens davon abhält. Aber wenn es keinen solchen Bedarf gibt, braucht man auch kein OOP.
Wladimir:
Es stellt sich heraus, dass OOP die automatische Parallelisierung von Berechnungen verhindert. Heutzutage sollte es als ein sehr ernster Nachteil angesehen werden, die Perspektive ist nicht für OOP.
Die Perspektive ist in Sprachen wie Systemverilog.
Das ist in Ordnung, bis auf die Tatsache, dass die Funktion isNewBar() überhaupt nicht existieren sollte. Es ist schon komisch, dass so viel um eine so triviale Sache herumgetanzt wird.
Es handelt sich nur um eine Variable, die einfach mit der Zeit des Taktes verglichen wird; wenn alle Fälle erfolgreich sind, wird der Variablen die Zeit des neuen Taktes am Ende zugewiesen. Andernfalls wird für alle Fälle nur ein Versuch angesetzt.
Das Hinzufügen zusätzlicher Begrenzungen an dieser Stelle wird die Lesbarkeit des Codes sofort erheblich erschweren und die Zahl möglicher Fehler erhöhen, wenn etwas nicht ankommt, weil es aufgrund dieser Begrenzungen auf dem Weg verloren gegangen ist.
Es ist genau das Gegenteil - die Grenzen erlauben es Ihnen, nicht darüber nachzudenken, "warum diese Variable, welche Rolle sie in diesem Fall spielt, sollte sie berücksichtigt werden?".
Der Benutzer hat nur Zugriff auf das, was er berücksichtigen muss, und nur auf das, was er ändern kann. Das sind genau die Fehler, "wenn etwas auf dem Weg verloren geht" - und sie entstehen gerade dadurch, dass zu viel vorhanden ist und etwas "auf dem Weg vergessen wird". Bei "abgeschnittenen" virtuellen Interessen ist dies sehr viel schwieriger zu bewerkstelligen.
Das einfachste Beispiel ist die Erlangung eines Arbeitsplatzes. Eine Position ist entweder ein offener Auftrag in MT4 oder eine offene Position in MT5.
Wenn Sie vollen Zugriff haben, muss sich der Benutzer bei der Auswahl einer Position daran erinnern, welche Variablen jetzt gelesen werden können, welche Variablen im Moment ungültig sind, welche Variablen er ändern kann und welche nicht.
Mit der Schnittstelle sind die Dinge viel einfacher. Sie haben es, und es hat nur zwei Funktionen: die Anzahl der Komponenten und einen Zeiger auf eine konstante Komponente. DAS WAR'S. Mit diesen beiden Funktionen haben Sie eigentlich keinen Zugriff auf "zusätzliche Variablen".
Andrej:
Natürlich verstehe ich den Wunsch, OOP wenigstens irgendwie für etwas Nützliches zu nutzen, aber solche Fälle liegen in der Regel nicht im Bereich der Programmierung, sondern im kommerziellen Bereich, wie z.B. zusätzliche Programmierstunden, endlose Diskussionen über die Architektur von Schnittstellen und dergleichen angenehmer Zeitvertreib in den Bürostunden.
Und dazu werden Sie früher oder später kommen. Außerdem kann die Kapselung in einem "rein prozeduralen" Ansatz durchgeführt werden. Der OOP-Ansatz ist jedoch bequemer, da man Vererbung und Polymorphismus "automatisch" erhält.
Ich weiß nicht, ob das schon jemand vorgeschlagen hat, aber warum sollte man nicht alles von MT4 auf MT5 umstellen, dann würde jeder weitermachen.
Das Problem ist nicht nur, dass in 4 etwas enthalten ist, das in 5 nicht enthalten ist. Und es ist nicht einmal das OOP.
5 hat den Händlern (nicht den Programmierern, nicht den Software-Händlern - nur den Händlern) praktisch nichts gebracht.
Eigenes Geschichtsformat, Verbot von Sonderanfertigungen - aber diese beiden Punkte haben jeden vergrault, der mit Geometrie handelt. Und keine "viele TFs" (ohne jährlich, lol), Skalen in Pips pro Bar wird sie anziehen.
Eine einfache Frage. Was zeigt das "Raster"? Der Versuch, dies herauszufinden, wird Sie zu der Empfehlung führen, zu Freelancing zu gehen und zu bestellen, was immer Sie wollen.
MTs sind Terminals für Programmierer. Das ist die ganze Antwort.
Die Sache ist die, dass OOP nur auf die Verpackung des fertigen Codes anwendbar sein kann, in der Phase der Codeerstellung stört es nur. Aber wenn es keine solche Notwendigkeit gibt, gibt es auch keine Notwendigkeit in OOP.
Nein, das ist es nicht. Es ist genau andersherum.
Schnittstellen werden anfangs definiert, sogar "vor der Phase des Codeschreibens". Schnittstellen sind in der Tat alle die gleichen ToR für den Programmierer. Alle Interaktionen in Freelance werden unter Verwendung expliziter ToR durchgeführt. Die virtuellen Schnittstellen sind also eine Art TOR, an dem die Programmierung ansetzt.
Sie gehen, so wie ich es verstehe, einfach falsch an das Wesen von OOP heran. Man schreibt zuerst eine Reihe von Funktionen und muss sie dann in das OOP-Design "quetschen". Aber das ist ein falscher Weg. Der richtige Weg ist der umgekehrte - zuerst definieren Sie die OOP-Definition, also die grundlegenden Schnittstellen zwischen den Komponenten des Systems. Und dann wird eine Komponente nach der anderen nach diesen vordefinierten Schnittstellen geschrieben.
Ja, manchmal kommt es vor, dass wir beim Schreiben des Codes feststellen, dass die Schnittstelle für etwas nicht vorgesehen ist. Und dann fängst du an... "Ohhhh... Beim prozeduralen Ansatz hätte ich Zugang zu all dem, ich hätte kein Problem damit, das zu tun, was ich brauche, aber jetzt - wie bekomme ich Zugang zu diesen Variablen?". Das passiert, wenn in der Entwurfsphase von Schnittstellen etwas nicht berücksichtigt wurde. Das ist eine sehr unangenehme Situation - man muss entweder zusätzliche Schnittstellen hinzufügen oder die vorhandenen ändern, was mit Fehlern behaftet ist. Diese Situation sollte natürlich vermieden werden.
Hier das einfachste Beispiel: die Besetzung einer Stelle. Eine Position ist entweder ein offener Auftrag in MT4 oder eine offene Position in MT5.
Wenn Sie Vollzugriff haben, muss sich der Benutzer bei der Auswahl einer Position merken, welche Variablen jetzt gelesen werden können, welche Variablen derzeit ungültig sind, welche Variablen er ändern kann und welche nicht.
Mit der Schnittstelle sind die Dinge viel einfacher. Sie haben es, und es hat nur zwei Funktionen: die Anzahl der Komponenten und einen Zeiger auf eine konstante Komponente. DAS WAR'S. Mit diesen beiden Funktionen können Sie eigentlich auf keine "zusätzlichen Variablen" zugreifen.
Genau das Gegenteil ist der Fall. Die Benutzer benötigen oft interne Variablen, um beispielsweise die Qualität von Modulen zu prüfen, was nicht der Fall ist. Und es werden besondere raffinierte Methoden erfunden, um diesen Zugang anschließend zu erhalten. Es gibt also im Prinzip keine überflüssigen Informationen, und wer sie nicht braucht, kann sie einfach nicht nutzen.
Dies ist genau das Gegenteil. Die Benutzer müssen oft die internen Variablen kennen, um beispielsweise Qualitätsmodule zu testen, und das ist nicht der Fall. Und sie lassen sich besonders clevere Methoden einfallen, um diesen Zugang zu erhalten. Es gibt also keine unnötigen Informationen, und wer sie nicht braucht, nutzt sie einfach nicht.
Wenn Sie einen "geschickten Zugang brauchen, um ihn zu bekommen", deutet dies auf eine falsche Systemkonzeption hin.
Wenn wir zum Beispiel einen Generator für Eingangssignale schreiben, sollten wir keinen Zugang zu Informationen haben, die beispielsweise die Geldverwaltung betreffen.
Natürlich kann es bei der Fehlersuche zu einer Situation kommen, z. B. wenn es keine Eingabe gab - wir sollten die Situation sofort beseitigen, wenn es passiert ist, weil die Geldverwaltung die Operation verboten hat (z. B. weil es nicht genug Marge gibt). Und woher wissen Sie das vom Eintragsgenerator? Sie haben keinen - Sie haben keinen Zugang. Aber in diesem Fall - es ist genug, um sicherzustellen, dass der Generator ein Signal für die Eingabe gesetzt hat, und es funktionierte richtig. Es gab keine Eingabe - aus einem anderen Grund, der außerhalb des Eingabegenerators liegt. In diesem Fall ist es wirklich schwieriger, den Grund herauszufinden, als wenn wir direkten Zugang zu allen Variablen der Geldverwaltung haben. Viel gefährlicher ist jedoch, dass wir im normalen, routinemäßigen Betrieb - wenn wir Zugang zu ihnen haben - "an die falsche Stelle geraten".
Wenn ein "schwieriger Zugang" erforderlich ist, ist dies ein Hinweis auf eine fehlerhafte Systemgestaltung.
Entwicklung ist in erster Linie ein natürlicher Prozess des Geistes.
In diesem Prozess entstehen die Ideen frei und sogar spontan.
Die Befolgung einer OOP macht es schwierig, den Code frei zu transformieren.
Im natürlichen Prozess der Entwicklung schrumpft der Code selbst allmählich und wird universell.
Im natürlichen Prozess lösen sich die Funktionen nicht auf, sondern wachsen im Gegenteil und vereinigen sich zu großen Blöcken.
Große Blöcke lösen ein breites Spektrum von Aufgaben.
OOP verhindert, dass diese Blöcke entstehen und der Code fragmentiert bleibt.
OOP führt zu einem komplizierten Zugriff, der die Anzahl der Verweise auf Variablen ständig erhöht.
Die Vorteile der Granularität werden durch die Schwierigkeit, einen kohärenten Mechanismus zu schaffen, aufgewogen.
Der Hauptnachteil: OOP zwingt uns, den Code in eine Reihe von Funktionen aufzuteilen.
Für einen Menschen ist es einfacher, fragmentierten Code zu akzeptieren, aber Fragmentierung ist für jeden Mechanismus kontraindiziert.