Wird OOP in MQL5 gefragt sein? - Seite 2
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
Was interessiert Sie, der Prozess oder das Endergebnis?)
Ich bin an beidem interessiert, aber das Endergebnis ist irgendwie mehr. ("... OOP gibt Ihnen viele Möglichkeiten, Ihre Programme zu verlangsamen...")
Ich sehe nicht, wo OOP mir erlauben würde, schneller zu schreiben als mit einem prozeduralen Ansatz, und das würde alle Nachteile von OOP aufwiegen. Es ist klar, wer es braucht - der Entwickler, der für andere schreibt.
Ich möchte Ihnen ein Beispiel geben: Der erste nahm ein Messer und schnitzte eine filigrane Figur, während der zweite sich mit demselben Messer einen halben Finger abschnitt. Was ist der Sinn der Sache? Mit jedem Werkzeug kann man sowohl ein "Schätzchen" als auch einen totalen Penner schaffen. Es hängt alles vom Programmierer ab, ob er ein Handwerker ist oder ein Funken Talent hat. Dies ist eine Abschweifung, aber im Grunde genommen - wenn Sie FOP bevorzugen, dann verwenden Sie es weiter.
Bei der Erstellung des Themas wollte ich Argumente für OOP in Projekten für MT-Zwecke sehen. Vielleicht lag es an meiner Unwissenheit - ich will nicht kokettieren -, dass ich sie nicht gesehen habe. Ich sehe sie auch jetzt nicht.
Lassen Sie mich Ihre Beiträge zusammenfassen (übrigens vielen Dank an Sie alle):
1. Bequemlichkeit und Schnelligkeit der Projektdurchführung.
2. Wartung, Upgrades.
3. 5 ist schneller, denn wen interessiert schon, wie man programmiert.
3. Händigkeit als Grund für langsameres OOP.
------------
(achselzuckend) Verstehen Sie, dass ich nicht gegen OOP bin, ich wollte nur für mich selbst herausfinden, was es mir an Aufgaben für MT geben kann - bei der Erstellung von Indizes, Skripten, Expert Advisors.
GUT. Am 5. gibt es eine Hilfe. Wer kann ein Beispiel für einen einfachen indirekten MT4-Standard geben, der mit OOP auf 5? Dort werden Sie es sehen können. Sie können Verzögerungen auch nach Augenmaß anhand des Textes, der Lesbarkeit des Programms usw. abschätzen.
1. Die Bequemlichkeit und Schnelligkeit des Projekts.
2. Wartung, Upgrades.
1) OOP ist sehr praktisch für diejenigen, die die grundlegenden Prinzipien verstehen. Das spürt man selbst bei den einfachsten Anwendungen. Jede Anwendung ist mit OOP bequemer zu erstellen.
2. Der Umfang eines Projekts ist kein Hindernis, solange es nicht schwer zu verstehen ist. Und wenn ein Programm objektorientiert ist, ist es nicht sehr schwer, es zu verstehen. Ein Beispiel ist das SaxoBank-Terminal. Es ist in C# geschrieben, einer objektorientierten Sprache. Jede DLL enthält etwa 20 000 Codezeilen. Ohne OOP wäre es fast unmöglich, eine solche Menge an Informationen zu verstehen, und erst recht, sie zu modernisieren.
Sie haben kein OOP mehr in ihrem Kern (obwohl absolutes OOP praktisch unbrauchbar ist). Wir hätten von Anfang an abstrakte Klassen erstellen und Vererbung und Polymorphismus nutzen sollen, um zu echten Objekten zu gelangen. Zum Beispiel, um eine abstrakte Basisklasse für benutzerdefinierte Indikatoren mit abstrakten Methoden und Eigenschaften zu erstellen. Es ist besser, einen hierarchischen Baum von Klassen aufzubauen: einen Baum für grafische Objekte, für die Arbeit mit dem Konto, für Zeitpläne und den Zugang zu Zeitreihen usw. Und bei den vordefinierten Prozeduren und Funktionen sollten nur die elementaren Routinen übrig bleiben, die Geschwindigkeit erfordern. Dann könnte man die Fähigkeiten der Plattform auf jeder beliebigen Abstraktionsebene erweitern, was die Codegröße verringern und die Lesbarkeit und Verständlichkeit für andere Programmierer verbessern würde. Und MT5 hat bereits ziemlich komplexe Dinge auf Prozedurenebene implementiert (in der Tat ist die gesamte Plattform einsatzbereit) und ich habe nicht die Möglichkeit des Zugriffs durch Zeiger zumindest auf Deskriptoren der erstellten internen Strukturen gesehen, was sehr einschränkend ist (nach der Hilfe zu urteilen). Im Allgemeinen ist die Notwendigkeit von OOP fraglich, denn mit einer solchen Implementierung könnten wir uns auf Strukturen und dynamische Platzierung beschränken. OOP sollte von unten durch eine umfangreiche Klassenhierarchie unterstützt werden .
Man braucht 1-3 Jahre Programmierpraxis, um zu erkennen, dass Programme NICHT SCHREIBEN, sondern LESEN sind.
Es dauert weitere 1-2 Jahre, bis man erkennt, dass Programme nicht für einen Computer, sondern für einen Menschen (vor allem für sich selbst) geschrieben werden.
Dann dauert es 1-2 Jahre, bis man merkt, dass OOP und C++ der humanoiden Denkweise und der Methode, menschliche Sprachen zu entwickeln, widersprechen.
Es dauert weitere 1-2 Jahre, bis man den Code anderer Leute studiert und erkennt, dass die besten und zuverlässigsten Programme in klassischem Ce geschrieben sind.
Danach reicht es aus, Dijkstras Interview über C++ und OOP zu lesen, das ihm Bauchschmerzen bereitet.
Und danach (insgesamt 4-9 Jahre) stellen sich Fragen "über OOP" gar nicht mehr, und solche Diskussionen verursachen nur ein nachsichtiges Lächeln.
Und danach (insgesamt 4-9 Jahre) gibt es überhaupt keine Fragen mehr "über OOP", und solche Diskussionen rufen nur ein herablassendes Lächeln hervor.
>> Ich kann das nachvollziehen.