![MQL5 - Sprache von Handelsstrategien, eingebaut ins Kundenterminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Peter, du hast OOP wie ein rotes Tuch vor einer Zielscheibe. In keinem anderen Thread wird so viel über OOP diskutiert wie in diesem. Und das alles, obwohl Sie kein einziges Programm in eben dieser OOP geschrieben haben. Finden Sie das alles nicht seltsam?
Ich reagiere lediglich auf Vorschläge , OOP in meinem Ansatz zu verwenden. Diese Ansätze sind nicht miteinander vereinbar.
Ich werde also meinen Ansatz erläutern, ohne zu erklären, warum ich darin keine OOP-Syntax verwende.
Wenn ich es nicht benutze, dann ist es auch nicht nötig.
Beide Thesen sind falsch.
Ziehen Sie den Themenstarter hier nicht schon 6 Seiten lang, aber es ist nicht klar, was er zeigen will, es ist klar, dass es um den Kernel geht ))))
er wird uns ein Beispiel zeigen und dann werden wir ihn davon überzeugen, dass OOP bei der Softwareentwicklung Zeit spart ;)
Wenn ich es nicht benutze, gibt es auch keinen Grund, es zu benutzen.
Wenn man etwas nicht versteht, kann man es nicht gebrauchen. Was auch immer Sie also in Ihren Mega-Bibliotheken vorhaben, es wird für OOP "nicht notwendig" sein.
Wenn man etwas nicht versteht, kann man es nicht gebrauchen. Was auch immer Sie also in Ihren Mega-Bibliotheken haben, es besteht dort "keine Notwendigkeit" für OOP.
Beginnen wir also mit einer einfachen Frage. Erstellen wir ein Prototyp-Element innerhalb des Proto-Kerns:
Das Element wird also im Proto-Kern in erweiterter, tabellarischer Form dargestellt.
Die tabellarische Darstellung hat ihre Vorteile. Vor allem in Schleifen.
Schreiben wir nun eine Funktion, mit der ein Element erstellt wird.
Doch zunächst sollten wir die Eigenschaften des Objekts über Defines definieren, damit man sich leicht auf sie beziehen kann.
//Вот как будут выглядеть обращения к свойствам элемента: P_CORE[BASE][X] P_CORE[BASE][Y] P_CORE[BASE][X_SIZE] P_CORE[BASE][Y_SIZE] P_CORE[BASE][COLOR] P_CORE[TEXT][X] P_CORE[TEXT][Y] P_CORE[TEXT][X_SIZE] P_CORE[TEXT][Y_SIZE] P_CORE[TEXT][COLOR] P_CORE[ICON][X] P_CORE[ICON][Y] P_CORE[ICON][X_SIZE] P_CORE[ICON][Y_SIZE] P_CORE[ICON][COLOR]
Wir schreiben eine Funktion, die eine Schaltfläche erstellt:
Natürlich werden einige sagen, dass der Kernel unnötig ist. Ein Anruf wie dieser reicht aus:
und alles wird wie früher sein. Ja, aber nur am Anfang. Das Problem bei einem solchen Aufruf ist, dass er nicht richtig entwickelt werden kann.
Die Eigenschaften der einzelnen Elemente müssen im globalen Speicher organisiert und auf einfachste Weise zugänglich sein.